T0895 Autorun Image: Disabling and Detecting AutoRun on OT Hosts

Autorun Image (T0895) is an adversary getting code to run on an OT host simply by presenting media, physical or virtual, to a system still configured to run it automatically. Legacy operating systems and long-lived SCADA images often keep AutoRun settings that IT estates removed years ago, and virtualised control systems add a new route: anyone with hypervisor access can attach a disk image to a guest without touching the guest itself. MITRE ATT&CK for ICS lists T0895 under the Execution tactic (TA0104) for Embedded, Linux and Windows platforms, with one mitigation, M0928 Operating System Configuration. This guide is for OT security engineers and virtualisation administrators responsible for SCADA and HMI hosts. It covers the 2022 Ukraine case, the Windows and Linux settings involved, ATT&CK's v20 analytics, and a safe rollout. For removable media as an initial access route, see the MITRE ATT&CK for ICS T0847 Replication Through Removable Media guide.

Key takeaways

• One setting decides this technique. ATT&CK's mitigation is to configure operating systems to disable autorun of specific file types or drives.
• Virtual media counts. ATT&CK highlights virtual machines where disk images can be mapped to a guest from the hypervisor, with no prior remote access to the guest.
• It happened to a power grid. In the 2022 Ukraine Electric Power Attack, Sandworm mapped an ISO image to a SCADA server virtual machine whose operating system was configured to autorun CD-ROM images.
• CD-ROM is the gap to check. Windows AutoRun policy distinguishes drive types, and a host can have AutoRun turned off for USB but left on for optical drives, which is how virtual ISOs appear.
• Protect the hypervisor like the SCADA host. Whoever administers the virtualisation layer can present media to every OT guest it runs.

What T0895 covers in OT

ATT&CK for ICS describes T0895 as adversaries using AutoRun functionality or scripts to execute code from removable media such as USB drives or ISO disk images, on devices that have AutoRun enabled or run legacy operating systems. ATT&CK notes that AutoRun or AutoPlay is commonly disabled in many operating system configurations, so the exposure is in hosts that were built or kept differently, which in OT is common: vendor-built images, systems frozen at commissioning, and hosts that rarely receive policy updates. ATT&CK's own example is an adversary who reaches a hypervisor management interface, changes a virtual machine's hardware configuration and attaches an ISO with an AutoRun script. The Enterprise matrix has no direct equivalent; the closest are T1091 Replication Through Removable Media and the persistence entries in T1547 Boot or Logon Autostart Execution.

The case: 2022 Ukraine Electric Power Attack

ATT&CK records that during the 2022 Ukraine Electric Power Attack (C0034) Sandworm used existing hypervisor access to map an ISO image to a virtual machine running a SCADA server, and that the server's operating system was configured to autorun CD-ROM images, so a VBS script on the image ran automatically. Mandiant's report adds that this happened on 10 October 2022, that the script launched a batch file which likely ran MicroSCADA's own scilc.exe utility to send commands to substations, and that the event coincided with an unplanned power outage. Mandiant mapped the ISO step to T0847; ATT&CK v20 maps it to T0895, and maps the scilc.exe step to T0894 System Binary Proxy Execution.

The lesson is that the guest's hardening did not matter once the attacker was on the hypervisor and the guest still accepted autorun from its virtual optical drive. Both conditions were configuration choices. See the Sandworm Threat Actor Profile.

Prevention: M0928 on Windows and Linux

Windows settings

Microsoft documents three AutoPlay policies under Computer Configuration, Administrative Templates, Windows Components, AutoPlay Policies, also available through the Policy CSP for Windows 10 version 1703 and later. Computer Configuration settings take precedence over User Configuration where they conflict.

Microsoft's AutoRun documentation states that AutoRun from media runs only when the root of the media holds an Autorun.inf file, the drive is not disabled through the registry and the foreground application has not suppressed it, and it warns that AutoRun on removable media is an easy vector for viruses. Microsoft also notes that Windows Explorer must restart for registry changes to NoDriveTypeAutoRun to take effect, so plan a reboot or logoff window with operations.

Linux settings

ATT&CK's Linux analytic looks at udev rules and autofs configuration that trigger script execution when removable media is mounted. On Linux SCADA, historian and HMI hosts, review udev rules and automount configuration for anything that runs a program on mount, mount removable media without execute permission where the distribution supports it, and remove desktop automount behaviour on hosts that do not need it.

Hypervisor controls

Restrict who can change virtual hardware on OT virtual machines, remove virtual optical drives from guests that do not need them, and keep hypervisor management networks and credentials separate from IT. See the Hypervisor and Virtualisation Security Guide.

Detection: ATT&CK v20 analytics

ATT&CK v20's detection strategy for T0895 applies its OT operational fidelity gate: alert when execution breaks an approved signer, hash, path, parent or tool allowlist, or comes from an unauthorised user or tool, and is tied to an OT asset, while suppressing vendor-signed software, approved engineering utilities and documented maintenance.

Add two signals the analytics imply. On the hypervisor, alert on media being attached to OT virtual machines outside a change window, using its audit or event log. On the guest, alert on script hosts such as wscript.exe or cmd.exe spawned with a working path on an optical or removable drive. See the ESXi Logs Detection Guide where ESXi hosts OT workloads.

Where identity fits

Virtual media can be attached only by an account with rights on the virtualisation layer. Hypervisor administrator accounts, and the service accounts of management tools that can reconfigure guests, effectively have physical access to every OT virtual machine. Give them named identities, multi-factor authentication, no shared credentials with the IT virtualisation estate, and alerting on use outside change windows. See the OT and ICS Identity and Access Guide.

How to implement

1. Survey current settings. Collect AutoPlay policy and NoDriveTypeAutoRun values from every Windows OT host, and udev and automount configuration from Linux hosts, without changing anything.
2. Confirm with vendors. Check whether any SCADA or HMI installation or update process relies on AutoRun from media, and agree an alternative.
3. Pilot on a test or redundant host. Apply the policies, restart Explorer or the host in a planned window, and confirm operator functions still work.
4. Roll out by zone. Apply through Group Policy, CSP or local policy for standalone hosts, in rings that match maintenance windows.
5. Harden the virtualisation layer. Remove unneeded virtual optical drives and restrict virtual hardware changes to named administrators.
6. Turn on detection for autorun configuration changes, media attachment on hypervisors and script hosts started from removable or optical drives.
7. Keep a rollback. Record previous values; a policy can be reverted per host if a vendor process genuinely needs it, with a dated exception.

Decision guidance

• Domain-joined OT hosts: apply the Group Policy settings centrally from an OT domain, not the IT domain.
• Standalone and legacy hosts: set local policy or registry values during maintenance and record them in the host's build sheet; check after every vendor reimage.
• Virtualised SCADA: treat hypervisor administration as part of the control system security boundary, with its own access path.
• Small sites: a one-time settings change and a check after each vendor visit removes most of the risk.
• Large sites: enforce through configuration management and report drift. See the Removable Media and USB Control Guide for the wider media programme.

Responding to suspected autorun execution

If media was attached or inserted and code ran, check the process state with operators first, since the follow-on step may already have issued commands. Preserve the media or ISO, the hypervisor event log, the guest's process history and network captures. Detach the media and block the host's path to field devices at the conduit, coordinated with operations. Review hypervisor accounts for compromise, since the Ukraine attacker already had that access. See the OT Incident Response Guide.

Detection and measurement

• Setting coverage: share of Windows OT hosts with AutoRun disabled for all drive types, including CD-ROM.
• Linux coverage: share of Linux OT hosts with no script execution on mount.
• Virtual drive exposure: number of OT virtual machines with virtual optical drives attached.
• Hypervisor access: number of accounts able to change OT virtual machine hardware.
• Drift: hosts found with AutoRun re-enabled after vendor work or reimaging.

Framework mapping

Common failure patterns

• USB disabled, CD-ROM left on: the condition Sandworm used through a virtual optical drive.
• Vendor images restore old defaults: a reimage after a support visit quietly re-enables AutoRun.
• Hypervisor shared with IT: IT virtualisation administrators or compromised IT accounts can present media to OT guests.
• Policy set in the user scope only: service and operator accounts the policy does not reach still autorun media.
• No logging on the virtualisation layer: media attachment leaves no record to investigate.

Practitioner checklist

• Disable AutoPlay and AutoRun for all drive types, including CD-ROM, on every Windows OT host.
• Remove script execution on mount from Linux OT hosts.
• Remove virtual optical drives from OT virtual machines that do not need them.
• Restrict virtual hardware changes to named, MFA-protected hypervisor administrators.
• Alert on autorun configuration changes and on script hosts started from optical or removable drives.
• Log and alert on media attachment to OT virtual machines.
• Recheck settings after every vendor visit or reimage.
• Compare field device firmware hashes against an authorised inventory after reboots.

Standards and references

• MITRE ATT&CK for ICS: Autorun Image (T0895)
• MITRE ATT&CK: 2022 Ukraine Electric Power Attack (C0034)
• Mandiant: Sandworm Disrupts Power in Ukraine Using a Novel Attack Against Operational Technology
• Microsoft Learn: Autoplay Policy CSP
• Microsoft Learn: Using the Registry to Disable AutoRun
• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security

Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · MITRE ATT&CK for ICS T0847 Replication Through Removable Media · Removable Media and USB Control Guide · Hypervisor and Virtualisation Security Guide · Sandworm Threat Actor Profile