You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[Rule Tuning] AWS EC2 Instance Console Login via Assumed Role (#5285)
* [Rule Tuning] AWS EC2 Instance Console Login via Assumed Role
No hits in telemetry for this rule yet. Which is good as it is extremely rare and high-risk behavior for an EC2 instance to exhibit any console login behavior.
- used `event.type` as event_category_override field to remove use of `any` in query
- updated description and investigation guide
- updated tags
- updated Mitre mapping
- added highlighted fields
* normalized Sign-In tag
normalized Sign-In tag
* fixing Mitre mapping
* Update rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
---------
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
Identifies a successful console login activity by an EC2 instance profile using an assumed role. This is uncommon behavior and could indicate an attacker using compromised credentials to further exploit an environment. An EC2 instance assumes a role using their EC2 ID as the session name. This rule looks for the pattern "i-" which is the beginning pattern for assumed role sessions started by an EC2 instance and a successful `ConsoleLogin` or `GetSigninToken` API call.
10
+
Detects successful AWS Management Console or federation login activity performed using an EC2 instance’s assumed role
11
+
credentials. EC2 instances typically use temporary credentials to make API calls, not to authenticate interactively via
12
+
the console. A successful "ConsoleLogin" or "GetSigninToken" event using a session pattern that includes "i-" (the EC2
13
+
instance ID) is highly anomalous and may indicate that an adversary obtained the instance’s temporary credentials from
14
+
the instance metadata service (IMDS) and used them to access the console. Such activity can enable lateral movement,
15
+
privilege escalation, or persistence within the AWS account.
11
16
"""
12
-
false_positives = ["This is very uncommon behavior and should result in minimal false positives, ensure validity of the triggered event and include exceptions where necessary."]
17
+
event_category_override = "event.type"
18
+
false_positives = [
19
+
"""
20
+
This is very uncommon behavior and should result in minimal false positives, ensure validity of the triggered event
21
+
and include exceptions where necessary.
22
+
""",
23
+
]
13
24
from = "now-6m"
14
25
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
15
26
language = "eql"
16
27
license = "Elastic License v2"
17
28
name = "AWS EC2 Instance Console Login via Assumed Role"
29
+
note = """## Triage and analysis
30
+
31
+
> **Disclaimer**:
32
+
> 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.
33
+
34
+
### Investigating AWS EC2 Instance Console Login via Assumed Role
35
+
36
+
This rule detects successful AWS console or federation logins using temporary credentials tied to EC2 instance profiles. Under normal conditions, EC2 instances use their temporary credentials for programmatic API access — **not** for interactive console sessions. When an attacker gains access to an instance’s IMDS (Instance Metadata Service) or its environment variables, they may retrieve temporary STS credentials and attempt console logins to gain full access to the AWS account. A successful login of this type is rare and high-risk, as it strongly suggests credential theft or unauthorized session hijacking.
37
+
38
+
#### Possible investigation steps
39
+
40
+
- **Identify the source and actor**
41
+
- Review `aws.cloudtrail.user_identity.arn`, `user.id`, and `user_agent.original` fields to confirm the session originated from an EC2 instance (`:i-` pattern).
42
+
- Correlate the instance ID (`i-xxxxxx`) with the specific EC2 instance in your environment to identify its owner, purpose, and running applications.
43
+
- Check `source.ip` and `cloud.region` to determine if the login originated from within AWS infrastructure (expected) or an external location (suspicious).
44
+
45
+
- **Correlate surrounding activity**
46
+
- Pivot in Timeline to view the sequence of events leading up to the login, including:
- Calls to the IMDS endpoint or local credential exfiltration attempts from the instance.
49
+
- Investigate whether the same role or credentials were used for API actions following the login (e.g., `CreateUser`, `AttachRolePolicy`, or `ListBuckets`).
50
+
51
+
- **Assess IAM role exposure**
52
+
- Determine which IAM role was associated with the instance at the time of the event and review its attached permissions.
53
+
- Evaluate whether the role grants console access or permissions beyond what that workload normally requires.
54
+
- Check for any recent changes to that role’s trust policy or attached policies.
55
+
56
+
- **Validate authorization**
57
+
- Contact the EC2 instance owner or service team to confirm if any legitimate process should be logging in to the console.
58
+
- If no legitimate activity can explain the login, treat the credentials as compromised.
59
+
60
+
### False positive analysis
61
+
62
+
This is very uncommon behavior.
63
+
Known legitimate causes include:
64
+
- AWS or internal security automation that programmatically initiates console sessions for validation or testing.
65
+
- Forensic or incident-response automation that logs in using temporary credentials from a compromised instance.
66
+
- Red-team or penetration-testing activity designed to validate IMDS exposure or lateral movement scenarios.
67
+
68
+
For any other occurrence, treat the alert as potentially malicious.
69
+
Validate through:
70
+
- The originating instance’s purpose and owner.
71
+
- Known automation patterns in `user_agent.original`.
72
+
- The timestamp alignment with planned testing or security validation.
73
+
74
+
### Response and remediation
75
+
76
+
- **Immediate containment**
77
+
- Revoke the temporary credentials for the affected role (`aws sts revoke-session-token` or rotate the role credentials).
78
+
- Isolate the associated EC2 instance (e.g., detach it from the VPC or security groups) to prevent further credential misuse.
79
+
- Invalidate active console sessions via AWS CLI or the AWS Console.
80
+
81
+
- **Investigation and scoping**
82
+
- Review CloudTrail logs for all actions associated with the compromised role in the preceding 24 hours.
83
+
- Determine if additional roles or instances show similar `ConsoleLogin` patterns.
84
+
- Search for network indicators of IMDS exploitation (e.g., requests to `169.254.169.254` from unauthorized binaries or users).
85
+
86
+
- **Recovery and hardening**
87
+
- Rotate all credentials for affected roles and users.
88
+
- Apply IMDSv2 enforcement to prevent credential harvesting from EC2 metadata.
89
+
- Implement restrictive IAM policies: deny console access (`iam:PassRole`, `sts:GetFederationToken`) for non-human roles.
90
+
91
+
### Additional information
92
+
- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)**
- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
and event.action in ("ConsoleLogin", "GetSigninToken")
43
123
and event.outcome == "success"
44
124
and aws.cloudtrail.user_identity.type == "AssumedRole"
45
125
and stringContains (user.id, ":i-")
46
126
'''
47
-
note = """## Triage and analysis
48
-
49
-
> **Disclaimer**:
50
-
> 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.
51
-
52
-
### Investigating AWS EC2 Instance Console Login via Assumed Role
53
-
54
-
AWS EC2 instances can assume roles to access resources securely, using temporary credentials. This mechanism, while essential for legitimate operations, can be exploited by adversaries who gain access to EC2 credentials, allowing them to assume roles and perform unauthorized actions. The detection rule identifies unusual console login activities by EC2 instances, flagging potential misuse by checking for specific session patterns and successful login events, thus helping to uncover lateral movement or credential access attempts.
55
-
56
-
### Possible investigation steps
57
-
58
-
- Review the CloudTrail logs for the specific event where event.dataset is "aws.cloudtrail" and event.provider is "signin.amazonaws.com" to gather more details about the login event.
59
-
- Identify the EC2 instance associated with the session by examining the user.id field for the pattern ":i-" and correlate it with known EC2 instance IDs in your environment.
60
-
- Check the AWS CloudTrail logs for any other activities performed by the same assumed role session to identify any unauthorized actions or lateral movement attempts.
61
-
- Investigate the source IP address and geolocation of the login event to determine if it aligns with expected access patterns for your organization.
62
-
- Verify the IAM role policies and permissions associated with the assumed role to assess the potential impact of the unauthorized access.
63
-
- Review recent changes to the IAM roles and policies to identify any unauthorized modifications that could have facilitated the assumed role access.
64
-
- Contact the instance owner or relevant team to confirm if the login activity was expected or authorized, and take appropriate action if it was not.
65
-
66
-
### False positive analysis
67
-
68
-
- Routine administrative tasks: EC2 instances may assume roles for legitimate administrative purposes, such as automated deployments or maintenance tasks. To manage this, identify and whitelist known administrative session patterns or specific instance IDs that regularly perform these tasks.
69
-
- Monitoring and logging services: Some monitoring or logging services might use assumed roles to access AWS resources for data collection. Review and exclude these services by identifying their specific session patterns or instance IDs.
70
-
- Scheduled jobs or scripts: Automated scripts or scheduled jobs running on EC2 instances might assume roles for resource access. Document these jobs and create exceptions for their session patterns to prevent false alerts.
71
-
- Development and testing environments: Instances in development or testing environments might frequently assume roles for testing purposes. Consider excluding these environments from the rule or creating specific exceptions for known testing activities.
72
-
- Third-party integrations: Some third-party tools or integrations might require EC2 instances to assume roles for functionality. Verify these integrations and exclude their session patterns or instance IDs from triggering alerts.
73
-
74
-
### Response and remediation
75
-
76
-
- Immediately revoke the temporary credentials associated with the compromised EC2 instance to prevent further unauthorized access.
77
-
- Isolate the affected EC2 instance from the network to contain any potential lateral movement by the attacker.
78
-
- Conduct a thorough review of CloudTrail logs to identify any unauthorized actions performed using the assumed role and assess the extent of the compromise.
79
-
- Reset and rotate all credentials and access keys associated with the compromised EC2 instance and any other potentially affected resources.
80
-
- Implement stricter IAM policies and role permissions to limit the scope of access for EC2 instances, ensuring the principle of least privilege is enforced.
81
-
- Notify the security operations team and relevant stakeholders about the incident for further investigation and to initiate any necessary legal or compliance procedures.
82
-
- Enhance monitoring and alerting mechanisms to detect similar patterns of unusual console login activities in the future, ensuring rapid response to potential threats."""
0 commit comments