Suspicious Instance Metadata Service (IMDS) API Request
This rule identifies various tools/scripts performing network activities attempting to access the cloud service provider's instance metadata service (IMDS) API endpoint, which can be used to retrieve sensitive instance-specific information such as instance ID, public IP address, and even temporary security credentials if roles are assumed by that instance.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/05/22"
3integration = ["endpoint"]
4maturity = "production"
5updated_date = "2026/05/22"
6
7[rule]
8author = ["Elastic"]
9description = """
10This rule identifies various tools/scripts performing network activities attempting to access the cloud service provider's
11instance metadata service (IMDS) API endpoint, which can be used to retrieve sensitive instance-specific information such
12as instance ID, public IP address, and even temporary security credentials if roles are assumed by that instance.
13"""
14from = "now-9m"
15index = ["logs-endpoint.events.network-*"]
16language = "kuery"
17license = "Elastic License v2"
18name = "Suspicious Instance Metadata Service (IMDS) API Request"
19note = """## Triage and analysis
20
21> **Disclaimer**:
22> 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.
23
24### Investigating Suspicious Instance Metadata Service (IMDS) API Request
25
26This alert flags command interpreters, scripting engines, or unusual binaries on a host trying to contact the local instance metadata service, a high-value source of instance details and temporary cloud credentials. A common attacker pattern is gaining code execution on a Linux or Windows VM, then using curl, PowerShell, or a script dropped in a temporary directory to query 169.254.169.254 and harvest the attached role credentials for follow-on cloud access.
27
28### Possible investigation steps
29
30- Review the full execution chain and any referenced script or binary contents to determine whether the metadata request came from approved bootstrap or agent activity versus an interactive shell, web application process, scheduled job, or recently dropped file.
31- Identify the initiating account, session context, and trigger for the execution to separate expected automation from hands-on-keyboard behavior, especially if it followed a remote login, privilege escalation, or exploitation event.
32- Correlate the host and timeframe with cloud control-plane telemetry to confirm whether instance role credentials or managed identity tokens were later used against storage, secrets, IAM, subscription, or other sensitive APIs.
33- Examine nearby endpoint activity for follow-on collection and staging behavior such as writing token output to disk, exporting environment data, invoking cloud CLIs or SDKs, compressing files, or making outbound connections to unfamiliar destinations.
34- Validate with the asset owner whether the workload legitimately requires IMDS access, and if the activity is unexplained, contain the host and rotate any exposed instance profile or managed identity credentials.
35
36### False positive analysis
37
38- A legitimate bootstrap, login, or scheduled administration script may use curl, PowerShell, or Python to query 169.254.169.254 for instance ID, public IP, or temporary role credentials during normal configuration, so verify the command line, parent process, and execution timing match expected startup or maintenance activity from an approved path.
39- An approved in-house application or service may call IMDS through a shell or runtime such as java, node, or python to obtain instance-specific settings or cloud authentication at runtime, so confirm the binary or script is expected on that host and that the requests align with normal service startup behavior rather than a new interactive session or a temporary-directory executable.
40
41### Response and remediation
42
43- Isolate the affected instance or host from the network or move it to a containment security group, terminate active remote sessions, and preserve volatile evidence such as the running process tree, shell history, temporary scripts, and recent command output tied to the 169.254.169.254 request.
44- Revoke or rotate any cloud role credentials, API keys, tokens, and application secrets that may have been exposed through IMDS, and detach or replace the instance profile or managed identity if it granted access beyond the workload’s normal needs.
45- Remove the attacker’s foothold by deleting the script or binary that queried IMDS and eradicating associated persistence such as cron jobs, systemd services, rc.local changes, scheduled tasks, Run keys, WMI event subscriptions, launch agents, or modified shell startup files.
46- Restore the system from a known-good image or snapshot when integrity is in doubt, validate that no unauthorized users, SSH keys, services, or startup items remain, and reset credentials for any local, domain, or service accounts used on the host.
47- Escalate to incident response and cloud security immediately if IMDS returned temporary role credentials, if that role was used from unfamiliar IP addresses or regions, or if similar metadata queries are observed on multiple hosts, and expand scoping to all resources reachable by the compromised role.
48- Harden the environment by enforcing IMDSv2 or the cloud provider’s strongest metadata protections, disabling metadata access where unnecessary, blocking local access to 169.254.169.254 for unapproved processes, reducing instance-role privileges, and preventing script execution from temporary or user-writable directories.
49"""
50references = [
51 "https://hackingthe.cloud/aws/general-knowledge/intro_metadata_service/",
52 "https://www.wiz.io/blog/imds-anomaly-hunting-zero-day",
53]
54risk_score = 47
55rule_id = "ad02da2f-443d-454c-a12e-d9e6c65831ff"
56severity = "medium"
57tags = [
58 "Domain: Endpoint",
59 "Domain: Cloud",
60 "OS: Linux",
61 "OS: Windows",
62 "OS: macOS",
63 "Use Case: Threat Detection",
64 "Tactic: Credential Access",
65 "Tactic: Discovery",
66 "Data Source: Elastic Defend",
67 "Resources: Investigation Guide",
68]
69timestamp_override = "event.ingested"
70type = "new_terms"
71query = '''
72event.category:"network" and host.os.type:("windows" or "macos" or "linux") and
73 (destination.ip:"169.254.169.254" or destination.address :"169.254.169.254") and destination.port:"80" and (
74 process.name:(
75 "bash" or "dash" or "sh" or "tcsh" or "tclsh" or "wish" or "csh" or "zsh" or "ksh" or "fish" or
76 "mksh" or "busybox" or "ld.so" or "ld-linux-x86-64.so.2" or "bun" or "bun.exe" or "node" or "node.exe" or
77 "nodejs" or "deno" or "deno.exe" or "java" or "java.exe" or "env" or "timeout" or "setsid" or "flock" or
78 "curl" or "curl.exe" or "wget" or "wget.exe" or "powershell.exe" or "cmd.exe" or "pwsh.exe" or
79 "wscript.exe" or "cscript.exe" or "regsvr32.exe" or "mshta.exe" or "rundll32.exe" or "vbc.exe" or
80 "msbuild.exe" or "wmic.exe" or "cmstp.exe" or "RegAsm.exe" or "installutil.exe" or "RegSvcs.exe" or
81 "msxsl.exe" or "xwizard.exe" or "csc.exe" or "pwsh" or python* or perl* or ruby* or lua* or php* or
82 "terminal" or "osascript" or "nohup" or .* or "javaw" or "javaw.exe"
83 ) or
84 process.executable:(
85 ./* or /boot/* or /dev/shm/* or /run/* or /var/run/* or /tmp/* or /var/tmp/* or /var/www/* or
86 /home/*/* or /root/* or /private/var/tmp/* or /var/folders/* or /Users/Shared/* or /var/root/*
87 )
88) and
89not (
90 (
91 host.os.type:"macos" and
92 process.name:"node"
93 ) or
94 (
95 process.name:"Cursor Helper (Plugin)" and
96 process.code_signature.trusted:true and
97 process.code_signature.signing_id:"com.github.Electron.helper"
98 ) or
99 (
100 process.name:"Code Helper (Plugin)" and
101 process.code_signature.trusted:true and
102 process.code_signature.signing_id:("com.microsoft.VSCode.helper" or "com.github.Electron.helper")
103 ) or
104 process.executable:/vscode/vscode-server/bin/linux-x64/*/node
105)
106'''
107
108[[rule.threat]]
109framework = "MITRE ATT&CK"
110
111[[rule.threat.technique]]
112id = "T1552"
113name = "Unsecured Credentials"
114reference = "https://attack.mitre.org/techniques/T1552/"
115
116[[rule.threat.technique.subtechnique]]
117id = "T1552.005"
118name = "Cloud Instance Metadata API"
119reference = "https://attack.mitre.org/techniques/T1552/005/"
120
121[rule.threat.tactic]
122id = "TA0006"
123name = "Credential Access"
124reference = "https://attack.mitre.org/tactics/TA0006/"
125
126[[rule.threat]]
127framework = "MITRE ATT&CK"
128
129[[rule.threat.technique]]
130id = "T1016"
131name = "System Network Configuration Discovery"
132reference = "https://attack.mitre.org/techniques/T1016/"
133
134[[rule.threat.technique]]
135id = "T1082"
136name = "System Information Discovery"
137reference = "https://attack.mitre.org/techniques/T1082/"
138
139[[rule.threat.technique]]
140id = "T1580"
141name = "Cloud Infrastructure Discovery"
142reference = "https://attack.mitre.org/techniques/T1580/"
143
144[rule.threat.tactic]
145id = "TA0007"
146name = "Discovery"
147reference = "https://attack.mitre.org/tactics/TA0007/"
148
149[rule.new_terms]
150field = "new_terms_fields"
151value = ["host.id", "process.executable"]
152
153[[rule.new_terms.history_window_start]]
154field = "history_window_start"
155value = "now-7d"
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 Suspicious Instance Metadata Service (IMDS) API Request
This alert flags command interpreters, scripting engines, or unusual binaries on a host trying to contact the local instance metadata service, a high-value source of instance details and temporary cloud credentials. A common attacker pattern is gaining code execution on a Linux or Windows VM, then using curl, PowerShell, or a script dropped in a temporary directory to query 169.254.169.254 and harvest the attached role credentials for follow-on cloud access.
Possible investigation steps
- Review the full execution chain and any referenced script or binary contents to determine whether the metadata request came from approved bootstrap or agent activity versus an interactive shell, web application process, scheduled job, or recently dropped file.
- Identify the initiating account, session context, and trigger for the execution to separate expected automation from hands-on-keyboard behavior, especially if it followed a remote login, privilege escalation, or exploitation event.
- Correlate the host and timeframe with cloud control-plane telemetry to confirm whether instance role credentials or managed identity tokens were later used against storage, secrets, IAM, subscription, or other sensitive APIs.
- Examine nearby endpoint activity for follow-on collection and staging behavior such as writing token output to disk, exporting environment data, invoking cloud CLIs or SDKs, compressing files, or making outbound connections to unfamiliar destinations.
- Validate with the asset owner whether the workload legitimately requires IMDS access, and if the activity is unexplained, contain the host and rotate any exposed instance profile or managed identity credentials.
False positive analysis
- A legitimate bootstrap, login, or scheduled administration script may use curl, PowerShell, or Python to query 169.254.169.254 for instance ID, public IP, or temporary role credentials during normal configuration, so verify the command line, parent process, and execution timing match expected startup or maintenance activity from an approved path.
- An approved in-house application or service may call IMDS through a shell or runtime such as java, node, or python to obtain instance-specific settings or cloud authentication at runtime, so confirm the binary or script is expected on that host and that the requests align with normal service startup behavior rather than a new interactive session or a temporary-directory executable.
Response and remediation
- Isolate the affected instance or host from the network or move it to a containment security group, terminate active remote sessions, and preserve volatile evidence such as the running process tree, shell history, temporary scripts, and recent command output tied to the 169.254.169.254 request.
- Revoke or rotate any cloud role credentials, API keys, tokens, and application secrets that may have been exposed through IMDS, and detach or replace the instance profile or managed identity if it granted access beyond the workload’s normal needs.
- Remove the attacker’s foothold by deleting the script or binary that queried IMDS and eradicating associated persistence such as cron jobs, systemd services, rc.local changes, scheduled tasks, Run keys, WMI event subscriptions, launch agents, or modified shell startup files.
- Restore the system from a known-good image or snapshot when integrity is in doubt, validate that no unauthorized users, SSH keys, services, or startup items remain, and reset credentials for any local, domain, or service accounts used on the host.
- Escalate to incident response and cloud security immediately if IMDS returned temporary role credentials, if that role was used from unfamiliar IP addresses or regions, or if similar metadata queries are observed on multiple hosts, and expand scoping to all resources reachable by the compromised role.
- Harden the environment by enforcing IMDSv2 or the cloud provider’s strongest metadata protections, disabling metadata access where unnecessary, blocking local access to 169.254.169.254 for unapproved processes, reducing instance-role privileges, and preventing script execution from temporary or user-writable directories.
References
Related rules
- Suspicious Instance Metadata Service (IMDS) API Command Line Execution
- Multi-Cloud CLI Token and Credential Access Commands
- Kubectl Secrets Enumeration Across All Namespaces
- GenAI Process Accessing Sensitive Files
- Credential Access via TruffleHog Execution