* [Rule Tuning][New BBR Rule] AWS Sign-In Token Creation and Console Login
### Tuning - "AWS Signin Single Factor Console Login with Federated User"
Rule scope change and name change to match
- This original rule description suggests that it was designed to capture console login sessions by a Federated User without the use of MFA. However, AWS does not capture MFA usage for Federated Users (only for Root and IAM users). Federated identities will often use 3rd party IDP apps like Okta to enforce MFA, that data is not captured in Cloudtrail. So, the fields `MFAUsed` of `mfaAuthenticated` will always show as False/No in Cloudtrail.
- I changed the scope of this rule to simply capture Console Login by a Federated User. For security reasons this behavior should be correlated with 3rd party IDP data to ensure MFA was established by the identity requesting the Federated Console login. This is very low noise behavior both in telemetry and prod data.
- added highlighted fields
- edited investigation guide to align with scope change
### New BBR
- `GetSigninToken` exchanges existing temporary AWS credentials (e.g., from STS GetFederationToken or AssumeRole) for a short-lived sign-in token that is embedded in a one-click URL to the AWS Management Console.
- ConsoleLogin API often follows a `GetSignInToken` request in normal operations. However, suspicious circumstances like both requests coming from different IPs or geo locations might indicate some form of compromise and should be investigated.
- This BBR rule is created to capture all successful `GetSigninToken` requests for any identity type. It can be used for further correlation with other rules or as an investigative/hunting rule during alert triage.
* adding FederatedUser to query
adding FederatedUser to query
* changed ig title to match rule name
changed ig title to match rule name
* toml-lint
Isai
7e1f815334