Security teams detect autorun image by finding storage media or files that are configured to launch software automatically when mounted or opened. Inspect removable media controls, endpoint policies, and execution logs for unexpected autorun behaviour or new media-triggered processes. Disable automatic execution where possible, block unauthorised media, and alert on unapproved launch chains.
What autorun image detection actually looks for
autorun image detection is about finding media or files that are configured to start code automatically when a device mounts them, opens them, or browses to them. The practical signal is not the image format itself, but the combination of removable media, launch configuration, and execution that happens without an explicit user decision.
On endpoints, that means watching for unexpected process starts linked to inserted media, newly mounted volumes, or file types that trigger handlers. A reliable detection approach should correlate policy state, media insertion events, and process creation so teams can separate normal software deployment from a hidden launch path.
Where to inspect for autorun behaviour
Security teams should inspect three places together: removable media controls, endpoint execution policy, and launch telemetry. The media layer shows whether a device or image is allowed, the policy layer shows whether automatic execution is blocked, and the telemetry layer shows whether a process still launched despite those controls.
For deeper validation, look for unexpected chain-of-events patterns such as insertion, mount, file discovery, and immediate process creation. That sequence is more useful than checking only for a file name or extension, because adversaries often rely on whatever the operating system or shell will execute automatically.
When the subject sits in industrial or OT-adjacent environments, the OT Security Guide is useful because autorun-style behaviour can matter on engineering stations, removable maintenance media, and other systems where a launch chain can affect operational software.
How teams distinguish benign media from suspicious launch chains
Not every mounted image is malicious, so the detection problem is really a trust problem. A benign image is usually tied to an approved software distribution path, a known publisher, or an expected maintenance workflow. A suspicious image is one that introduces execution intent without an obvious business reason, especially when it appears outside an approved software-handling process.
That is why teams should compare observed autorun behaviour against approved media workflows and expected parent-child process relationships. A process spawned from removable media, especially if it launches script interpreters, command shells, or installers unexpectedly, deserves closer inspection than a routine mount event.
For teams that also manage software artefacts and mounted images in containerised or packaged workflows, the Container Image Security Guide provides a useful parallel lens on image trust, provenance, and unexpected execution paths.
Risk and Threat Considerations
Autorun behaviour is risky because it turns a simple storage object into an execution path. If attackers can place a crafted image or media item on a user device, they may gain code execution, persistence, or a foothold that bypasses normal download scrutiny and user caution.
Failure mechanism: Automatic launch settings, permissive media handling, or weak execution logging allow code to run as soon as the image is mounted or opened, before users recognise the media as untrusted.
Impact: Teams can miss the initial compromise, and the resulting execution may lead to malware installation, credential theft, lateral movement, or the compromise of systems that routinely ingest removable media.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Continuous Monitoring | Autorun detection depends on monitoring unexpected execution events from media. |
| Recommendation — Correlate mount events with process telemetry to detect unauthorized execution. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Autorun behaviour is identified by monitoring system events and launched processes. |
| AC-20 — Use of External Information Systems | Removable media is an external source that needs controlled use and restriction. | |
| Recommendation — Monitor endpoint event logs for media-triggered execution chains. Restrict and approve removable media use before allowing execution paths. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | Autorun images are a malware delivery path that endpoint defenses should block or detect. |
| Recommendation — Block auto-execution from untrusted media and alert on suspicious launches. | ||
| MITRE ATT&CK | T1204 — User Execution | Autorun image abuse relies on execution triggered by user or system interaction. |
| Recommendation — Map media-triggered launches to user-execution patterns and hunt accordingly. | ||
Practitioner Guidance
What to verify: Confirm that autorun or equivalent auto-execution features are disabled on all systems that do not explicitly need them, and verify that exceptions are documented with an owner and a business justification. If the control depends on policy alone, test whether local overrides or legacy handlers can still trigger execution.
What to measure: Track media-triggered process starts, blocked execution attempts, and the number of devices that still allow automatic launch from mounted media. Those signals show whether the problem is controlled in practice, not just in configuration.
Decision rule: If a process starts from removable media, treat it as a security event first and a software-delivery event second. If the media is not part of an approved deployment path, isolate the endpoint and inspect for any other execution or persistence tied to that mount.
Practitioner takeaway: The goal is not to eliminate every removable image, but to ensure that no image can become an unobserved execution path without policy, logging, and a defensible business need.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org