[New Rule] Adding Coverage for `AWS IAM or STS API Calls via Temporary Session Tokens`

[terrancedejesus]

Pull Request

Issue link(s):

• https://github.com/elastic/ia-trade-team/issues/585

Summary - What I changed

Adds detection coverage for AWS IAM or STS API Calls via Temporary Session Tokens.

Detects use of sensitive AWS STS or IAM API operations using temporary credentials (session tokens starting with 'ASIA'). This may indicate credential theft or abuse of elevated access via a stolen session. It is not common for legitimate users to perform sensitive IAM operations with temporary session tokens.

Additional Information:

• We expect this rule to be tuned over time.
• IAM or STS service API calls with user session tokens are not allowed unless MFA context is in the user session token because of sensitivity
• Typically IAM or STS calls are made with long-term creds, the console, cloud formation or IaC, making this an anomaly
• We focus solely on user identity type being IAMUser as assumed role typically will lead to FPs from service-based workflows requesting temp creds from STS to go about operations

How To Test

• Please review the referenced meta for emulation behavior.
• Query can be used in serverless stack to check for accuracy.

Checklist

• [ ] Added a label for the type of pr: bug, enhancement, schema, maintenance, Rule: New, Rule: Deprecation, Rule: Tuning, Hunt: New, or Hunt: Tuning so guidelines can be generated
• [ ] Added the meta:rapid-merge label if planning to merge within 24 hours
• [ ] Secret and sensitive material has been managed correctly
• [ ] Automated testing was updated or added to match the most common scenarios
• [ ] Documentation and comments were added for features that require explanation

Contributor checklist

• Have you signed the contributor license agreement?
• Have you followed the contributor guidelines?

[github-actions[bot]]

Rule: New - Guidelines

These guidelines serve as a reminder set of considerations when proposing a new rule.

Documentation and Context

• [ ] Detailed description of the rule.
• [ ] List any new fields required in ECS/data sources.
• [ ] Link related issues or PRs.
• [ ] Include references.

Rule Metadata Checks

• [ ] creation_date matches the date of creation PR initially merged.
• [ ] min_stack_version should support the widest stack versions.
• [ ] name and description should be descriptive and not include typos.
• [ ] query should be inclusive, not overly exclusive, considering performance for diverse environments. Non ecs fields should be added to non-ecs-schema.json if not available in an integration.
• [ ] min_stack_comments and min_stack_version should be included if the rule is only compatible starting from a specific stack version.
• [ ] index pattern should be neither too specific nor too vague, ensuring it accurately matches the relevant data stream (e.g., use logs-endpoint.process-* for process data).
• [ ] integration should align with the index. If the integration is newly introduced, ensure the manifest, schemas, and new_rule.yaml template are updated.
• [ ] setup should include the necessary steps to configure the integration.
• [ ] note should include any additional information (e.g. Triage and analysis investigation guides, timeline templates).
• [ ] tags should be relevant to the threat and align/added to the EXPECTED_RULE_TAGS in the definitions.py file.
• [ ] threat, techniques, and subtechniques should map to ATT&CK always if possible.

New BBR Rules

• [ ] building_block_type should be included if the rule is a building block and the rule should be located in the rules_building_block folder.
• [ ] bypass_bbr_timing should be included if adding custom lookback timing to the rule.

Testing and Validation

• [ ] Provide evidence of testing and detecting the expected threat.
• [ ] Check for existence of coverage to prevent duplication.

[imays11]

@terrancedejesus I can't find the emulation details in the Meta you linked. What type of behavior are you hoping to capture here for IAM? From my research into STS abuse I learned that STS short-term tokens created by GetSessionToken cannot interact with IAM service (i.e CreateUser), however those created by AssumeRole can. Since you're excluding assumedRole identity types then what are you expecting to capture related to IAM? And then for STS, what sort of behavior are you trying to capture?

[terrancedejesus]

Hey @imays11, thanks for taking a look!

What type of behavior are you hoping to capture here for IAM?

The goal is to ultimately identify IAM API calls with temporary user session tokens. Which while accepted with MFA context in the session token, would be an interesting signal vs using long-term creds, the console or some IdP. DPRK leveraged stolen temp creds for the ByBit attack then attempted to register an MFA device with them which ultimately requires the IAM API endpoint.

From my research into STS abuse I learned that STS short-term tokens created by GetSessionToken cannot interact with IAM service (i.e CreateUser), however those created by AssumeRole can.

Ref: https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html

You can make certain IAM calls with temporary tokens from GetSessionToken as long as MFA context exists in the token itself. Typically you would create a virtual device, register it with the IAM user and then enable. Note I have not tested CRUD operations extensively for this. But I can to be sure, which would influence risk ultimately if allowed or not.

To demonstrate this I...

1. Setup long-term creds locally with one of our AWS IAM users, setting their creds as the default profile for the CLI
2. Created a virtual MFA device - create-virtual-mfa-device (linking it to the profile for the CLI)
3. Enabled that device - enable-mfa-device
4. Retrieved temporary user session creds

get-session-token \
  --serial-number "$ARN" (ARN of the new MFA device) \
  --token-code "$FINAL_CODE" \
  --duration-seconds 43200 \
  --profile "$AWS_PROFILE" \
  --output json

5. Creds were saved as environment variables (AWS CLI prioritizes these first)
6. Launched an IAM API operation script we wrote for our ByBit emulation behavior to check enumerate acceptable vs non-acceptable API calls with the temp creds. (Ping me if you want this.)
7. Checked our stack for CloudTrail logs showcasing this. Note - since permissions are inherited, the IAM user I have has AdministratorAccess attached.

And then for STS, what sort of behavior are you trying to capture?

I threw STS in there to see what API operations were being called with temporary creds in general. We can remove these and keep it strictly IAM.

If you want to chat more about this, happy to! Just ping me.

[imays11]

Thank you for the additional details!

You can make certain IAM calls with temporary tokens from GetSessionToken as long as MFA context exists in the token itself. Typically you would create a virtual device, register it with the IAM user and then enable. Note I have not tested CRUD operations extensively for this. But I can to be sure, which would influence risk ultimately if allowed or not.

Ahh I missed this MFA exception. I do think we should test which type of operations are actually allowed. From your image it looks like really only "Read" type operations and if that's the case you can probably reduce the risk score. But this would also just be good information to know in general. I know this was part of your OnWeek project so let me know if you'd like me to test this more extensively as part of BAU AWS work

Launched an IAM API operation script we wrote for our ByBit emulation behavior to check enumerate acceptable vs non-acceptable API calls with the temp creds. (Ping me if you want this.)

Yes I would love this thank you!

I threw STS in there to see what API operations were being called with temporary creds in general. We can remove these and keep it strictly IAM.

Yea maybe this rule should stay focused on IAM. In those docs it says "You cannot call any AWS STS API except AssumeRole or GetCallerIdentity."

We have this Role Chaining rule to cover AssumeRole and this Discovery new terms rule to cover GetCallerIdentity.

[terrancedejesus]

@imays11

From your image it looks like really only "Read" type operations and if that's the case you can probably reduce the risk score.

I agree, reduced to low.

I do think we should test which type of operations are actually allowed.

I'll test these more extensively this morning.

Yea maybe this rule should stay focused on IAM. In those docs it says "You cannot call any AWS STS API except AssumeRole or GetCallerIdentity."

Agreed. Removed STS from name and query logic.

I also updated the investigation guide.

[terrancedejesus]

We have confirmed that with temporary creds you can do CRUD-based IAM API operations on existing assets in AWS.

Thanks again @imays11 for the extra attention here!