AWS STS GetSessionToken Abuse
Identifies the suspicious use of GetSessionToken. Tokens could be created and used by attackers to move laterally and escalate privileges.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2021/05/17"
3integration = ["aws"]
4maturity = "production"
5updated_date = "2025/01/15"
6
7[rule]
8author = ["Austin Songer"]
9description = """
10Identifies the suspicious use of GetSessionToken. Tokens could be created and used by attackers to move laterally and
11escalate privileges.
12"""
13false_positives = [
14 """
15 GetSessionToken may be done by a system or network administrator. Verify whether the user identity, user agent,
16 and/or hostname should be making changes in your environment. GetSessionToken from unfamiliar users or hosts should
17 be investigated. If known behavior is causing false positives, it can be exempted from the rule.
18 """,
19]
20index = ["filebeat-*", "logs-aws.cloudtrail-*"]
21language = "kuery"
22license = "Elastic License v2"
23name = "AWS STS GetSessionToken Abuse"
24note = """## Triage and analysis
25
26> **Disclaimer**:
27> 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.
28
29### Investigating AWS STS GetSessionToken Abuse
30
31AWS Security Token Service (STS) provides temporary credentials for AWS resources, crucial for managing access without long-term credentials. Adversaries may exploit GetSessionToken to create temporary credentials, enabling lateral movement and privilege escalation. The detection rule identifies successful GetSessionToken requests by IAM users, flagging potential misuse for further investigation.
32
33### Possible investigation steps
34
35- Review the CloudTrail logs for the specific GetSessionToken event to gather details about the IAM user involved, including the time of the request and the source IP address.
36- Check the IAM user's activity history to identify any unusual patterns or deviations from their normal behavior, such as accessing resources they typically do not use.
37- Investigate the source IP address from which the GetSessionToken request originated to determine if it is associated with known malicious activity or if it is an unexpected location for the user.
38- Examine the permissions and roles associated with the temporary credentials issued by the GetSessionToken request to assess the potential impact of their misuse.
39- Correlate the GetSessionToken event with other security events or alerts in the same timeframe to identify any related suspicious activities or potential indicators of compromise.
40
41### False positive analysis
42
43- Routine administrative tasks by IAM users can trigger GetSessionToken requests. To manage this, identify and whitelist IAM users or roles that regularly perform these tasks as part of their job functions.
44- Automated scripts or applications that use GetSessionToken for legitimate purposes may cause false positives. Review and document these scripts, then create exceptions for their activity in the detection rule.
45- Scheduled jobs or services that require temporary credentials for periodic tasks might be flagged. Ensure these are documented and excluded from alerts by adjusting the rule to recognize their specific patterns.
46- Development and testing environments often generate GetSessionToken requests during normal operations. Consider excluding these environments from the rule or adjusting the risk score to reflect their lower threat level.
47- Cross-account access scenarios where users from one account access resources in another using temporary credentials can appear suspicious. Verify these access patterns and exclude them if they are part of regular operations.
48
49### Response and remediation
50
51- Immediately revoke the temporary credentials associated with the suspicious GetSessionToken request to prevent further unauthorized access.
52- Conduct a thorough review of the IAM user's activity logs to identify any unauthorized actions or access patterns that may indicate lateral movement or privilege escalation.
53- Isolate any affected resources or accounts to contain potential threats and prevent further exploitation.
54- Reset the credentials of the IAM user involved and enforce multi-factor authentication (MFA) to enhance security.
55- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation.
56- Implement additional monitoring and alerting for unusual GetSessionToken requests to detect similar activities in the future.
57- Review and tighten IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of privilege escalation.
58
59## Setup
60
61The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
62references = ["https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html"]
63risk_score = 21
64rule_id = "b45ab1d2-712f-4f01-a751-df3826969807"
65severity = "low"
66tags = [
67 "Domain: Cloud",
68 "Data Source: AWS",
69 "Data Source: Amazon Web Services",
70 "Data Source: AWS STS",
71 "Use Case: Identity and Access Audit",
72 "Tactic: Privilege Escalation",
73 "Resources: Investigation Guide",
74]
75timestamp_override = "event.ingested"
76type = "query"
77
78query = '''
79event.dataset:aws.cloudtrail and event.provider:sts.amazonaws.com and event.action:GetSessionToken and
80aws.cloudtrail.user_identity.type:IAMUser and event.outcome:success
81'''
82
83
84[[rule.threat]]
85framework = "MITRE ATT&CK"
86[[rule.threat.technique]]
87id = "T1548"
88name = "Abuse Elevation Control Mechanism"
89reference = "https://attack.mitre.org/techniques/T1548/"
90
91
92[rule.threat.tactic]
93id = "TA0004"
94name = "Privilege Escalation"
95reference = "https://attack.mitre.org/tactics/TA0004/"
96[[rule.threat]]
97framework = "MITRE ATT&CK"
98[[rule.threat.technique]]
99id = "T1550"
100name = "Use Alternate Authentication Material"
101reference = "https://attack.mitre.org/techniques/T1550/"
102[[rule.threat.technique.subtechnique]]
103id = "T1550.001"
104name = "Application Access Token"
105reference = "https://attack.mitre.org/techniques/T1550/001/"
106
107
108
109[rule.threat.tactic]
110id = "TA0008"
111name = "Lateral Movement"
112reference = "https://attack.mitre.org/tactics/TA0008/"
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 GetSessionToken Abuse
AWS Security Token Service (STS) provides temporary credentials for AWS resources, crucial for managing access without long-term credentials. Adversaries may exploit GetSessionToken to create temporary credentials, enabling lateral movement and privilege escalation. The detection rule identifies successful GetSessionToken requests by IAM users, flagging potential misuse for further investigation.
Possible investigation steps
- Review the CloudTrail logs for the specific GetSessionToken event to gather details about the IAM user involved, including the time of the request and the source IP address.
- Check the IAM user's activity history to identify any unusual patterns or deviations from their normal behavior, such as accessing resources they typically do not use.
- Investigate the source IP address from which the GetSessionToken request originated to determine if it is associated with known malicious activity or if it is an unexpected location for the user.
- Examine the permissions and roles associated with the temporary credentials issued by the GetSessionToken request to assess the potential impact of their misuse.
- Correlate the GetSessionToken event with other security events or alerts in the same timeframe to identify any related suspicious activities or potential indicators of compromise.
False positive analysis
- Routine administrative tasks by IAM users can trigger GetSessionToken requests. To manage this, identify and whitelist IAM users or roles that regularly perform these tasks as part of their job functions.
- Automated scripts or applications that use GetSessionToken for legitimate purposes may cause false positives. Review and document these scripts, then create exceptions for their activity in the detection rule.
- Scheduled jobs or services that require temporary credentials for periodic tasks might be flagged. Ensure these are documented and excluded from alerts by adjusting the rule to recognize their specific patterns.
- Development and testing environments often generate GetSessionToken requests during normal operations. Consider excluding these environments from the rule or adjusting the risk score to reflect their lower threat level.
- Cross-account access scenarios where users from one account access resources in another using temporary credentials can appear suspicious. Verify these access patterns and exclude them if they are part of regular operations.
Response and remediation
- Immediately revoke the temporary credentials associated with the suspicious GetSessionToken request to prevent further unauthorized access.
- Conduct a thorough review of the IAM user's activity logs to identify any unauthorized actions or access patterns that may indicate lateral movement or privilege escalation.
- Isolate any affected resources or accounts to contain potential threats and prevent further exploitation.
- Reset the credentials of the IAM user involved and enforce multi-factor authentication (MFA) to enhance security.
- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation.
- Implement additional monitoring and alerting for unusual GetSessionToken requests to detect similar activities in the future.
- Review and tighten IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of privilege escalation.
Setup
The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
References
Related rules
- AWS STS AssumeRole with New MFA Device
- AWS STS AssumeRoot by Rare User and Member Account
- AWS STS Role Assumption by Service
- AWS STS Role Assumption by User
- AWS IAM Assume Role Policy Update