[Rule Tuning] AWS EC2 Instance Console Login via Assumed Role

rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml

@@ -2,19 +2,97 @@
 creation_date = "2024/07/24"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/11/05"
 
 [rule]
 author = ["Elastic"]
 description = """
-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.
+Detects successful AWS Management Console or federation login activity performed using an EC2 instance’s assumed role
+credentials. EC2 instances typically use temporary credentials to make API calls, not to authenticate interactively via
+the console. A successful "ConsoleLogin" or "GetSigninToken" event using a session pattern that includes "i-" (the EC2
+instance ID) is highly anomalous and may indicate that an adversary obtained the instance’s temporary credentials from
+the instance metadata service (IMDS) and used them to access the console. Such activity can enable lateral movement,
+privilege escalation, or persistence within the AWS account.
 """
-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."]
+event_category_override = "event.type"
+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.
+    """,
+]
 from = "now-6m"
 index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "AWS EC2 Instance Console Login via Assumed Role"
+note = """## 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 EC2 Instance Console Login via Assumed Role
+
+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.
+
+#### Possible investigation steps
+
+- **Identify the source and actor**
+  - Review `aws.cloudtrail.user_identity.arn`, `user.id`, and `user_agent.original` fields to confirm the session originated from an EC2 instance (`:i-` pattern).
+  - Correlate the instance ID (`i-xxxxxx`) with the specific EC2 instance in your environment to identify its owner, purpose, and running applications.
+  - Check `source.ip` and `cloud.region` to determine if the login originated from within AWS infrastructure (expected) or an external location (suspicious).
+
+- **Correlate surrounding activity**
+  - Pivot in Timeline to view the sequence of events leading up to the login, including:
+    - STS token retrievals (`GetSessionToken`, `AssumeRole`, `GetCallerIdentity`)
+    - Calls to the IMDS endpoint or local credential exfiltration attempts from the instance.
+  - Investigate whether the same role or credentials were used for API actions following the login (e.g., `CreateUser`, `AttachRolePolicy`, or `ListBuckets`).
+
+- **Assess IAM role exposure**
+  - Determine which IAM role was associated with the instance at the time of the event and review its attached permissions.
+  - Evaluate whether the role grants console access or permissions beyond what that workload normally requires.
+  - Check for any recent changes to that role’s trust policy or attached policies.
+
+- **Validate authorization**
+  - Contact the EC2 instance owner or service team to confirm if any legitimate process should be logging in to the console.
+  - If no legitimate activity can explain the login, treat the credentials as compromised.
+
+### False positive analysis
+
+This is very uncommon behavior.  
+Known legitimate causes include:
+- AWS or internal security automation that programmatically initiates console sessions for validation or testing.
+- Forensic or incident-response automation that logs in using temporary credentials from a compromised instance.
+- Red-team or penetration-testing activity designed to validate IMDS exposure or lateral movement scenarios.
+
+For any other occurrence, treat the alert as potentially malicious.  
+Validate through:
+- The originating instance’s purpose and owner.
+- Known automation patterns in `user_agent.original`.
+- The timestamp alignment with planned testing or security validation.
+
+### Response and remediation
+
+- **Immediate containment**
+  - Revoke the temporary credentials for the affected role (`aws sts revoke-session-token` or rotate the role credentials).
+  - Isolate the associated EC2 instance (e.g., detach it from the VPC or security groups) to prevent further credential misuse.
+  - Invalidate active console sessions via AWS CLI or the AWS Console.
+
+- **Investigation and scoping**
+  - Review CloudTrail logs for all actions associated with the compromised role in the preceding 24 hours.
+  - Determine if additional roles or instances show similar `ConsoleLogin` patterns.
+  - Search for network indicators of IMDS exploitation (e.g., requests to `169.254.169.254` from unauthorized binaries or users).
+
+- **Recovery and hardening**
+  - Rotate all credentials for affected roles and users.
+  - Apply IMDSv2 enforcement to prevent credential harvesting from EC2 metadata.
+  - Implement restrictive IAM policies: deny console access (`iam:PassRole`, `sts:GetFederationToken`) for non-human roles.
+
+### Additional information
+- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
+- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
+- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
+"""
 references = [
     "https://redcanary.com/blog/aws-sts/",
     "https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-custom-url.html/",
@@ -28,58 +106,24 @@ tags = [
     "Data Source: Amazon Web Services",
     "Data Source: AWS EC2",
     "Data Source: AWS STS",
+    "Data Source: AWS Sign-In",
     "Use Case: Identity and Access Audit",
     "Tactic: Lateral Movement",
     "Tactic: Credential Access",
+    "Tactic: Persistence",
     "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-any where event.dataset == "aws.cloudtrail"
+info where event.dataset == "aws.cloudtrail"
    and event.provider == "signin.amazonaws.com"
    and event.action in ("ConsoleLogin", "GetSigninToken")
    and event.outcome == "success"
    and aws.cloudtrail.user_identity.type == "AssumedRole"
    and stringContains (user.id, ":i-")
 '''
-note = """## 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 EC2 Instance Console Login via Assumed Role
-
-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.
-
-### Possible investigation steps
-
-- 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.
-- 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.
-- 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.
-- Investigate the source IP address and geolocation of the login event to determine if it aligns with expected access patterns for your organization.
-- Verify the IAM role policies and permissions associated with the assumed role to assess the potential impact of the unauthorized access.
-- Review recent changes to the IAM roles and policies to identify any unauthorized modifications that could have facilitated the assumed role access.
-- 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.
-
-### False positive analysis
-
-- 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.
-- 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.
-- 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.
-- 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.
-- 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.
-
-### Response and remediation
-
-- Immediately revoke the temporary credentials associated with the compromised EC2 instance to prevent further unauthorized access.
-- Isolate the affected EC2 instance from the network to contain any potential lateral movement by the attacker.
-- Conduct a thorough review of CloudTrail logs to identify any unauthorized actions performed using the assumed role and assess the extent of the compromise.
-- Reset and rotate all credentials and access keys associated with the compromised EC2 instance and any other potentially affected resources.
-- Implement stricter IAM policies and role permissions to limit the scope of access for EC2 instances, ensuring the principle of least privilege is enforced.
-- Notify the security operations team and relevant stakeholders about the incident for further investigation and to initiate any necessary legal or compliance procedures.
-- Enhance monitoring and alerting mechanisms to detect similar patterns of unusual console login activities in the future, ensuring rapid response to potential threats."""
 
 
 [[rule.threat]]
@@ -93,6 +137,7 @@ id = "T1021.007"
 name = "Cloud Services"
 reference = "https://attack.mitre.org/techniques/T1021/007/"
 
+
 [[rule.threat.technique]]
 id = "T1550"
 name = "Use Alternate Authentication Material"
@@ -103,17 +148,59 @@ name = "Application Access Token"
 reference = "https://attack.mitre.org/techniques/T1550/001/"
 
 
+
 [rule.threat.tactic]
 id = "TA0008"
 name = "Lateral Movement"
 reference = "https://attack.mitre.org/tactics/TA0008/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+[[rule.threat.technique.subtechnique]]
+id = "T1078.004"
+name = "Cloud Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/004/"
+
 
 
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
 [[rule.threat]]
 framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1552"
+name = "Unsecured Credentials"
+reference = "https://attack.mitre.org/techniques/T1552/"
+[[rule.threat.technique.subtechnique]]
+id = "T1552.005"
+name = "Cloud Instance Metadata API"
+reference = "https://attack.mitre.org/techniques/T1552/005/"
+
+
 
 [rule.threat.tactic]
 id = "TA0006"
 name = "Credential Access"
 reference = "https://attack.mitre.org/tactics/TA0006/"
 
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "user.name",
+    "user_agent.original",
+    "source.ip",
+    "aws.cloudtrail.user_identity.arn",
+    "aws.cloudtrail.user_identity.type",
+    "aws.cloudtrail.user_identity.access_key_id",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.response_elements",
+]
+