AWS EC2 Stop, Start, and User Data Modification Correlation
Identifies a short sequence of EC2 management APIs against the same instance that is consistent with modifying instance
user data and forcing it to run on the next boot: ModifyInstanceAttribute with user data, followed by stop and start.
Adversaries may update userData and cycle instance state so malicious scripts execute as root on Linux or as the
system context on Windows. This rule correlates successful StopInstances, StartInstances, and
ModifyInstanceAttribute events that reference userData within a five-minute window, grouped by instance,
user.name, account, source IP, and user agent. A hit requires exactly three distinct API names in that bucket.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/04/03"
3integration = ["aws"]
4maturity = "production"
5updated_date = "2026/09/18"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies a short sequence of EC2 management APIs against the same instance that is consistent with modifying instance
11user data and forcing it to run on the next boot: `ModifyInstanceAttribute` with user data, followed by stop and start.
12Adversaries may update `userData` and cycle instance state so malicious scripts execute as root on Linux or as the
13system context on Windows. This rule correlates successful `StopInstances`, `StartInstances`, and
14`ModifyInstanceAttribute` events that reference `userData` within a five-minute window, grouped by instance,
15`user.name`, account, source IP, and user agent. A hit requires exactly three distinct API names in that bucket.
16"""
17false_positives = [
18 """
19 Legitimate automation or administrators may change user data and restart instances during maintenance, image
20 baking, or configuration fixes. Review the caller identity, change tickets, and whether `user_agent.original` and
21 `source.ip` match known tooling and networks (the rule groups on both together with `user.name`).
22 """,
23]
24from = "now-20m"
25interval = "5m"
26language = "esql"
27license = "Elastic License v2"
28name = "AWS EC2 Stop, Start, and User Data Modification Correlation"
29note = """## Triage and analysis
30
31### Investigating AWS EC2 Stop, Start, and User Data Modification Correlation
32
33This detection aggregates successful EC2 `StopInstances`, `StartInstances`, and `ModifyInstanceAttribute` (with
34`userData` in request parameters) over **five-minute** windows. Rows are keyed by **instance ID** (`Esql.instance_id`
35from the grok on `aws.cloudtrail.request_parameters`), **`user.name`**, **`cloud.account.id`**, **`user_agent.original`**,
36and **`source.ip`**. The rule fires only when **`Esql.event_action_unique_count` is 3**, meaning all three API names
37appear in the same bucket—consistent with changing user data and cycling the instance to run it.
38
39The aggregated result does **not** include raw `request_parameters`; use the alert’s instance, account, user, IP, user
40agent, and time bucket to query CloudTrail for the underlying events and payloads.
41
42#### Possible investigation steps
43
44- **Interpret the alert columns**: Review `Esql.event_action_values` to confirm the three actions are present (typically
45 `ModifyInstanceAttribute`, `StopInstances`, `StartInstances`). Use `Esql.event_action_unique_count` to verify the
46 rule logic (expect `3`).
47- **Confirm the instance**: Use `Esql.instance_id` plus `cloud.account.id` in CMDB or AWS Resource Groups. Ensure the
48 grok-derived ID matches the instance you expect (multi-instance API calls can affect extraction).
49- **Identify the caller**: Tie `user.name` to an IAM user or role session name as shown in CloudTrail; for assumed roles,
50 pivot in raw logs on `aws.cloudtrail.user_identity.arn` and session context in the same time window.
51- **Validate client and origin**: Compare `user_agent.original` and `source.ip` to known admin workstations, bastions,
52 or CI/CD egress. The rule intentionally groups by these fields so unrelated sessions do not merge into one bucket.
53- **Recover user data context**: In CloudTrail (or the integration’s `aws.cloudtrail.request_parameters` on raw events),
54 inspect the `ModifyInstanceAttribute` record for `userData` and whether values are base64 or placeholders.
55- **Hunt for follow-on activity**: After the window, look for IAM changes, role assumption, or data access from the
56 instance or the same principal.
57
58### False positive analysis
59
60- **Infrastructure as code**: Terraform, Ansible, and Pulumi user agents are excluded, but other automation may still
61 match. Validate pipeline identity, change tickets, and whether stop/start is part of approved maintenance.
62- **Break-glass or support workflows**: Some teams modify user data and restart instances during recovery; confirm with
63 the workload owner.
64- **Shared `user.name` or NAT**: If many callers share one identity or IP, bucketing may still separate sessions when IP
65 or user agent differs; conversely, identical UA/IP across benign bulk operations can resemble this pattern—confirm
66 intent.
67
68### Response and remediation
69
70- If unauthorized, isolate the instance, revoke or restrict the principal’s EC2 permissions, and rotate any credentials
71 that may have been exposed in user data.
72- Prefer Secrets Manager or Parameter Store over long-lived secrets in user data.
73
74### Additional information
75
76- [AWS EC2 User Data](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)
77- [ModifyInstanceAttribute](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceAttribute.html)
78- [Local EC2 privilege escalation through user data](https://hackingthe.cloud/aws/exploitation/local_ec2_priv_esc_through_user_data)
79"""
80references = [
81 "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceAttribute.html",
82 "https://hackingthe.cloud/aws/exploitation/local_ec2_priv_esc_through_user_data",
83]
84risk_score = 73
85rule_id = "7e5c0e5a-95a5-404e-a5b0-278d35dc3325"
86severity = "high"
87tags = [
88 "Domain: Cloud",
89 "Data Source: AWS",
90 "Data Source: Amazon Web Services",
91 "Data Source: AWS EC2",
92 "Data Source: AWS CloudTrail",
93 "Use Case: Threat Detection",
94 "Tactic: Execution",
95 "Resources: Investigation Guide",
96 "Noise: Unknown",
97 "Performance: Normal",
98 "Rule Type: ES|QL",
99 "Platform: AWS",
100 "Service: AWS EC2",
101]
102timestamp_override = "event.ingested"
103type = "esql"
104
105query = '''
106FROM logs-aws.cloudtrail-*
107| WHERE event.provider == "ec2.amazonaws.com"
108 and event.outcome == "success"
109 and aws.cloudtrail.user_identity.type != "AWSService"
110 and not (
111 user_agent.original like "*Terraform*"
112 or user_agent.original like "*Ansible*"
113 or user_agent.original like "*Pulumi*"
114 ) and not source.address in ("cloudformation.amazonaws.com", "servicecatalog.amazonaws.com")
115 and
116 (
117 event.action in ("StopInstances", "StartInstances") or
118 (event.action == "ModifyInstanceAttribute" and aws.cloudtrail.request_parameters like "*userData=*")
119 )
120| grok aws.cloudtrail.request_parameters """instanceId=(?<Esql.instance_id>[^,}\]]+)"""
121| STATS Esql.event_action_unique_count = COUNT_DISTINCT(event.action),
122 Esql.event_action_values = VALUES(event.action) by Esql.instance_id, user.name, cloud.account.id, Esql.time_bucket = DATE_TRUNC(5 minute, @timestamp) , user_agent.original, source.ip, source.as.organization.name, source.geo.country_name
123| where Esql.event_action_unique_count == 3
124| Keep Esql.*, user.name, cloud.account.id, user_agent.original, source.ip, source.as.organization.name, source.geo.country_name
125'''
126
127
128[[rule.threat]]
129framework = "MITRE ATT&CK"
130
131[[rule.threat.technique]]
132id = "T1059"
133name = "Command and Scripting Interpreter"
134reference = "https://attack.mitre.org/techniques/T1059/"
135
136[[rule.threat.technique.subtechnique]]
137id = "T1059.009"
138name = "Cloud API"
139reference = "https://attack.mitre.org/techniques/T1059/009/"
140
141[rule.threat.tactic]
142id = "TA0002"
143name = "Execution"
144reference = "https://attack.mitre.org/tactics/TA0002/"
145
146[[rule.threat]]
147framework = "MITRE ATT&CK"
148
149[[rule.threat.technique]]
150id = "T1578"
151name = "Modify Cloud Compute Infrastructure"
152reference = "https://attack.mitre.org/techniques/T1578/"
153
154[rule.threat.tactic]
155id = "TA0005"
156name = "Defense Evasion"
157reference = "https://attack.mitre.org/tactics/TA0005/"
158
159[rule.investigation_fields]
160field_names = [
161 "Esql.event_action_unique_count",
162 "Esql.event_action_values",
163 "Esql.instance_id",
164 "user.name",
165 "cloud.account.id",
166 "user_agent.original",
167 "source.ip",
168 "Esql.time_bucket",
169]
Triage and analysis
Investigating AWS EC2 Stop, Start, and User Data Modification Correlation
This detection aggregates successful EC2 StopInstances, StartInstances, and ModifyInstanceAttribute (with
userData in request parameters) over five-minute windows. Rows are keyed by instance ID (Esql.instance_id
from the grok on aws.cloudtrail.request_parameters), user.name, cloud.account.id, user_agent.original,
and source.ip. The rule fires only when Esql.event_action_unique_count is 3, meaning all three API names
appear in the same bucket—consistent with changing user data and cycling the instance to run it.
The aggregated result does not include raw request_parameters; use the alert’s instance, account, user, IP, user
agent, and time bucket to query CloudTrail for the underlying events and payloads.
Possible investigation steps
- Interpret the alert columns: Review
Esql.event_action_valuesto confirm the three actions are present (typicallyModifyInstanceAttribute,StopInstances,StartInstances). UseEsql.event_action_unique_countto verify the rule logic (expect3). - Confirm the instance: Use
Esql.instance_idpluscloud.account.idin CMDB or AWS Resource Groups. Ensure the grok-derived ID matches the instance you expect (multi-instance API calls can affect extraction). - Identify the caller: Tie
user.nameto an IAM user or role session name as shown in CloudTrail; for assumed roles, pivot in raw logs onaws.cloudtrail.user_identity.arnand session context in the same time window. - Validate client and origin: Compare
user_agent.originalandsource.ipto known admin workstations, bastions, or CI/CD egress. The rule intentionally groups by these fields so unrelated sessions do not merge into one bucket. - Recover user data context: In CloudTrail (or the integration’s
aws.cloudtrail.request_parameterson raw events), inspect theModifyInstanceAttributerecord foruserDataand whether values are base64 or placeholders. - Hunt for follow-on activity: After the window, look for IAM changes, role assumption, or data access from the instance or the same principal.
False positive analysis
- Infrastructure as code: Terraform, Ansible, and Pulumi user agents are excluded, but other automation may still match. Validate pipeline identity, change tickets, and whether stop/start is part of approved maintenance.
- Break-glass or support workflows: Some teams modify user data and restart instances during recovery; confirm with the workload owner.
- Shared
user.nameor NAT: If many callers share one identity or IP, bucketing may still separate sessions when IP or user agent differs; conversely, identical UA/IP across benign bulk operations can resemble this pattern—confirm intent.
Response and remediation
- If unauthorized, isolate the instance, revoke or restrict the principal’s EC2 permissions, and rotate any credentials that may have been exposed in user data.
- Prefer Secrets Manager or Parameter Store over long-lived secrets in user data.
Additional information
References
Related rules
- AWS EC2 LOLBin Execution via SSM SendCommand
- AWS Batch Job Submitted with Container Override by Unusual Identity
- AWS Bedrock API Key Used for Destructive or Anti-Recovery Action
- AWS Discovery API Calls via CLI from a Single Resource
- AWS EC2 EBS Snapshot Shared or Made Public