AWS STS AssumeRole with New MFA Device
Identifies when a user has assumed a role using a new MFA device. Users can assume a role to obtain temporary credentials and access AWS resources using the AssumeRole API of AWS Security Token Service (STS). While a new MFA device is not always indicative of malicious behavior it should be verified as adversaries can use this technique for persistence and privilege escalation.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2024/10/25"
3integration = ["aws"]
4maturity = "production"
5updated_date = "2025/01/15"
6
7
8[rule]
9author = ["Elastic"]
10description = """
11Identifies when a user has assumed a role using a new MFA device. Users can assume a role to obtain temporary credentials and access AWS resources using the AssumeRole API of AWS Security Token Service (STS).
12While a new MFA device is not always indicative of malicious behavior it should be verified as adversaries can use this technique for persistence and privilege escalation.
13"""
14false_positives = [
15 "AWS administrators or automated processes might regularly assume roles for legitimate administrative purposes and to perform periodic tasks such as data backups, updates, or deployments.",
16]
17index = ["filebeat-*", "logs-aws.cloudtrail-*"]
18language = "kuery"
19license = "Elastic License v2"
20name = "AWS STS AssumeRole with New MFA Device"
21note = """## Triage and analysis
22
23> **Disclaimer**:
24> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
25
26### Investigating AWS STS AssumeRole with New MFA Device
27
28AWS Security Token Service (STS) allows users to assume roles and gain temporary credentials for accessing AWS resources. This process can involve Multi-Factor Authentication (MFA) for enhanced security. However, adversaries may exploit new MFA devices to maintain persistence or escalate privileges. The detection rule identifies successful role assumptions with new MFA devices, flagging potential misuse for further investigation.
29
30### Possible investigation steps
31
32- Review the event details in AWS CloudTrail to identify the user who assumed the role, focusing on the user.id field to determine if the user is legitimate and authorized to use the new MFA device.
33- Check the serialNumber in the aws.cloudtrail.flattened.request_parameters to verify the registration and legitimacy of the new MFA device associated with the role assumption.
34- Investigate the context of the AssumeRole action by examining the event.action field to understand if it was part of a legitimate workflow or an unusual activity.
35- Analyze the event.outcome field to confirm the success of the role assumption and cross-reference with any recent changes in user permissions or MFA device registrations.
36- Correlate the event with other logs or alerts to identify any patterns of suspicious behavior, such as multiple role assumptions or changes in MFA devices within a short timeframe.
37- Contact the user or relevant team to confirm if the new MFA device registration and role assumption were expected and authorized.
38
39### False positive analysis
40
41- New employee onboarding processes may trigger this rule when new MFA devices are issued. To manage this, create exceptions for known onboarding activities by correlating with HR records or onboarding schedules.
42- Routine device replacements or upgrades can result in new MFA devices being registered. Implement a process to track and verify device changes through IT support tickets or asset management systems.
43- Users with multiple roles or responsibilities might frequently switch roles using different MFA devices. Establish a baseline of normal behavior for these users and create exceptions for their typical activity patterns.
44- Organizational policy changes that require MFA updates can lead to multiple new MFA device registrations. Coordinate with security teams to whitelist these events during policy rollout periods.
45- Temporary contractors or third-party vendors may use new MFA devices when accessing AWS resources. Ensure that their access is logged and reviewed, and create temporary exceptions for their known access periods.
46
47### Response and remediation
48
49- Immediately revoke the temporary credentials associated with the assumed role to prevent unauthorized access to AWS resources.
50- Verify the legitimacy of the new MFA device by contacting the user or administrator associated with the role assumption. Confirm whether the device was intentionally registered and used.
51- If the new MFA device is determined to be unauthorized, disable or remove it from the user's account to prevent further misuse.
52- Conduct a review of recent AWS CloudTrail logs to identify any suspicious activities or patterns associated with the user or role in question, focusing on privilege escalation or lateral movement attempts.
53- Escalate the incident to the security operations team for further investigation and to determine if additional containment measures are necessary.
54- Implement additional monitoring and alerting for unusual MFA device registrations and role assumptions to enhance detection of similar threats in the future.
55- Review and update IAM policies and MFA device management procedures to ensure they align with best practices for security and access control.
56
57## Setup
58
59The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
60references = [
61 "https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html",
62 "https://github.com/RhinoSecurityLabs/cloudgoat/blob/d5863b80afd082d853f2e8df1955c6393695a4da/scenarios/iam_privesc_by_key_rotation/README.md",
63]
64risk_score = 21
65rule_id = "a22f566b-5b23-4412-880d-c6c957acd321"
66severity = "low"
67tags = [
68 "Domain: Cloud",
69 "Data Source: AWS",
70 "Data Source: Amazon Web Services",
71 "Data Source: AWS STS",
72 "Use Case: Identity and Access Audit",
73 "Tactic: Privilege Escalation",
74 "Tactic: Persistence",
75 "Tactic: Lateral Movement",
76 "Resources: Investigation Guide",
77]
78timestamp_override = "event.ingested"
79type = "new_terms"
80
81query = '''
82event.dataset:aws.cloudtrail
83 and event.provider:sts.amazonaws.com
84 and event.action:(AssumeRole or AssumeRoleWithSAML or AssumeRoleWithWebIdentity)
85 and event.outcome:success
86 and user.id:*
87 and aws.cloudtrail.flattened.request_parameters.serialNumber:*
88'''
89
90
91[[rule.threat]]
92framework = "MITRE ATT&CK"
93[[rule.threat.technique]]
94id = "T1556"
95name = "Modify Authentication Process"
96reference = "https://attack.mitre.org/techniques/T1556/"
97[[rule.threat.technique.subtechnique]]
98id = "T1556.006"
99name = "Multi-Factor Authentication"
100reference = "https://attack.mitre.org/techniques/T1556/006/"
101
102
103[rule.threat.tactic]
104id = "TA0003"
105name = "Persistence"
106reference = "https://attack.mitre.org/tactics/TA0003/"
107[[rule.threat]]
108framework = "MITRE ATT&CK"
109[[rule.threat.technique]]
110id = "T1548"
111name = "Abuse Elevation Control Mechanism"
112reference = "https://attack.mitre.org/techniques/T1548/"
113
114
115[rule.threat.tactic]
116id = "TA0004"
117name = "Privilege Escalation"
118reference = "https://attack.mitre.org/tactics/TA0004/"
119[[rule.threat]]
120framework = "MITRE ATT&CK"
121[[rule.threat.technique]]
122id = "T1550"
123name = "Use Alternate Authentication Material"
124reference = "https://attack.mitre.org/techniques/T1550/"
125[[rule.threat.technique.subtechnique]]
126id = "T1550.001"
127name = "Application Access Token"
128reference = "https://attack.mitre.org/techniques/T1550/001/"
129
130
131[rule.threat.tactic]
132id = "TA0008"
133name = "Lateral Movement"
134reference = "https://attack.mitre.org/tactics/TA0008/"
135
136[rule.new_terms]
137field = "new_terms_fields"
138value = ["user.id", "aws.cloudtrail.flattened.request_parameters.serialNumber"]
139[[rule.new_terms.history_window_start]]
140field = "history_window_start"
141value = "now-10d"
Triage and analysis
Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
Investigating AWS STS AssumeRole with New MFA Device
AWS Security Token Service (STS) allows users to assume roles and gain temporary credentials for accessing AWS resources. This process can involve Multi-Factor Authentication (MFA) for enhanced security. However, adversaries may exploit new MFA devices to maintain persistence or escalate privileges. The detection rule identifies successful role assumptions with new MFA devices, flagging potential misuse for further investigation.
Possible investigation steps
- Review the event details in AWS CloudTrail to identify the user who assumed the role, focusing on the user.id field to determine if the user is legitimate and authorized to use the new MFA device.
- Check the serialNumber in the aws.cloudtrail.flattened.request_parameters to verify the registration and legitimacy of the new MFA device associated with the role assumption.
- Investigate the context of the AssumeRole action by examining the event.action field to understand if it was part of a legitimate workflow or an unusual activity.
- Analyze the event.outcome field to confirm the success of the role assumption and cross-reference with any recent changes in user permissions or MFA device registrations.
- Correlate the event with other logs or alerts to identify any patterns of suspicious behavior, such as multiple role assumptions or changes in MFA devices within a short timeframe.
- Contact the user or relevant team to confirm if the new MFA device registration and role assumption were expected and authorized.
False positive analysis
- New employee onboarding processes may trigger this rule when new MFA devices are issued. To manage this, create exceptions for known onboarding activities by correlating with HR records or onboarding schedules.
- Routine device replacements or upgrades can result in new MFA devices being registered. Implement a process to track and verify device changes through IT support tickets or asset management systems.
- Users with multiple roles or responsibilities might frequently switch roles using different MFA devices. Establish a baseline of normal behavior for these users and create exceptions for their typical activity patterns.
- Organizational policy changes that require MFA updates can lead to multiple new MFA device registrations. Coordinate with security teams to whitelist these events during policy rollout periods.
- Temporary contractors or third-party vendors may use new MFA devices when accessing AWS resources. Ensure that their access is logged and reviewed, and create temporary exceptions for their known access periods.
Response and remediation
- Immediately revoke the temporary credentials associated with the assumed role to prevent unauthorized access to AWS resources.
- Verify the legitimacy of the new MFA device by contacting the user or administrator associated with the role assumption. Confirm whether the device was intentionally registered and used.
- If the new MFA device is determined to be unauthorized, disable or remove it from the user's account to prevent further misuse.
- Conduct a review of recent AWS CloudTrail logs to identify any suspicious activities or patterns associated with the user or role in question, focusing on privilege escalation or lateral movement attempts.
- Escalate the incident to the security operations team for further investigation and to determine if additional containment measures are necessary.
- Implement additional monitoring and alerting for unusual MFA device registrations and role assumptions to enhance detection of similar threats in the future.
- Review and update IAM policies and MFA device management procedures to ensure they align with best practices for security and access control.
Setup
The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
References
Related rules
- AWS STS Role Chaining
- AWS EC2 Instance Connect SSH Public Key Uploaded
- AWS EC2 Instance Console Login via Assumed Role
- AWS STS AssumeRoot by Rare User and Member Account
- AWS STS GetSessionToken Abuse