Malware with execution guardrails checks that it is on the intended target before doing anything, so it stays inert in sandboxes and on analysts' machines while running fully on yours. MITRE ATT&CK T1480 Execution Guardrails covers adversaries constraining execution to environment-specific conditions they expect on the target, such as network share names, attached devices, files, the joined Active Directory domain, local or external IP addresses, and the user-agent of a visiting browser. It has two sub-techniques in ATT&CK v20: T1480.001 Environmental Keying, which derives decryption keys from target values, and T1480.002 Mutual Exclusion, which uses a mutex or lock to control whether code runs. The technique sits in the Stealth tactic (TA0005) and applies to Windows, Linux, macOS and ESXi. This guide covers what guardrails mean for detection and analysis, the behaviour chains ATT&CK recommends hunting, how to analyse keyed samples, and why ATT&CK advises against trying to prevent the technique itself. It is for detection engineers, malware analysts and threat intelligence teams. Broader malware analysis is in the Malware Sandbox Guide; this page focuses on T1480.
Key takeaways
- Guardrails are the opposite of sandbox evasion. ATT&CK explains that sandbox evasion checks for known sandbox values and continues if none match, while guardrails check for an expected target value and continue only if it matches.
- Do not try to block the check. ATT&CK's only mitigation is M1055 Do Not Mitigate: preventing guardrails could make the malware run on systems it was meant to spare. Defend earlier in the chain instead.
- A guardrail keyed to your domain is intelligence. A sample that only runs when joined to your AD domain or on your IP ranges is evidence of a targeted operation.
- Hunt the discovery burst. ATT&CK's analytics look for rapid system and environment discovery followed by decryption or execution, which is how a guardrail check looks from the endpoint.
- Your own telemetry beats detonation. A keyed payload may never decrypt in a sandbox, so the process, file and network trail from the real host is often the only full record of what it did.
How execution guardrails work
ATT&CK describes guardrails as ensuring a payload only executes against an intended target and reducing collateral damage. The table groups the values recorded in ATT&CK's description and procedure examples.
| Guardrail type | What is checked | Examples recorded by ATT&CK |
|---|---|---|
| Host identity | Volume serial number, hostname, unique device identifiers | DEADEYE executes only on systems matching the victim's volume serial number, hostname or DNS domain |
| Domain and network | Joined AD domain, DNS domain, local or external IP, network share names | Named in the technique description; DEADEYE checks the DNS domain |
| Geography and language | Location of the victim machine | Tsundere Botnet checks location to avoid infecting machines in Commonwealth of Independent States countries |
| Allowlists and files | Presence of a configuration file, membership of an allowlist | Exbyte checks for a configuration file; RansomHub terminates without encrypting if the machine is on its allowlist |
| Running software | Process names, security products | CHIMNEYSWEEP runs a task when it finds a matching process name; TONESHELL behaves differently depending on whether specific antivirus processes are present |
| Browser and platform | User-agent string | The technique description notes servers that serve malware only to user-agents for exploitable platforms |
| Mutual exclusion (T1480.002) | A named mutex or lock file | Embargo and Qilin create mutexes; BPFDoor locks a runtime file under /var/run and exits if it cannot |
Environmental keying (T1480.001)
Environmental keying uses cryptography: the payload is encrypted with a key derived from target values, so without those exact values the code cannot be decrypted at all. ATT&CK notes this makes mitigation infeasible within the targeted environment and also frustrates analysis, because the payload cannot be recovered without the target's values.
Mutual exclusion (T1480.002)
A mutex is a locking mechanism that only one thread or process can hold at a time. Malware creates a system-wide mutex, or on Linux and macOS a lock file, with a known name; if it already exists, the new copy assumes the host is infected and stops. That prevents reinfection and duplicate encryption, and it gives defenders a durable indicator.
How T1480 relates to other analysis-evasion techniques
ATT&CK v20 places T1480 in the Stealth tactic alongside T1497 Virtualization/Sandbox Evasion and T1622 Debugger Evasion. In practice samples often combine them: a sandbox check, a debugger check and a target guardrail in sequence. The tactic overview is in the ATT&CK Stealth and Defense Impairment Tactics Guide.
Detection analytics
ATT&CK v20 publishes three detection strategies for T1480: DET0562 for environmental validation across platforms, DET0474 for the environmental keying discovery-to-decryption chain, and DET0132 for mutex-based guardrails.
| Analytic | Platform | Behaviour | Log sources named by ATT&CK |
|---|---|---|---|
| AN1551, AN1305 | Windows | Rapid discovery through WMI queries, registry enumeration, network share discovery and hostname or domain checks, then cryptographic operations or conditional logic, then execution or network activity | Security 4688, 4624, 4648; Sysmon 1, 3, 7, 8, 11, 13, 14, 22, 25; WMI-Activity 5857 to 5861; PowerShell 4103 to 4106 |
| AN1552, AN1306 | Linux | Bursts of uname, hostname, id, ifconfig or ip, mount and ps, filesystem checks for target paths, then crypto library use and payload execution | auditd execve, open, connect and PROCTITLE; syslog; osquery process events |
| AN1553, AN1307 | macOS | system_profiler, sw_vers, sysctl, dscl, networksetup and scutil discovery, security feature checks, then conditional execution | Unified log; FSEvents |
| AN1554 | ESXi | VM inventory and host configuration enumeration with vim-cmd and esxcli, vCenter membership checks, then selective deployment | ESXi shell and hostd logs |
| AN0372 | Windows | Named mutex created, followed by quick process exit or an alternate code path | Sysmon 1, 11 |
| AN0373, AN0374 | Linux, macOS | Lock file acquired on a predictable path (for example under /tmp or /var/run), followed by early exit or divergent behaviour | auditd open, flock, fcntl, exit_group; unified log |
Tuning
- Discovery threshold and window: ATT&CK suggests tuning the number of distinct discovery techniques within a time window; our suggested starting point is four or more distinct discovery actions within a few minutes from a non-admin process.
- Legitimate discovery: keep a list of admin accounts, inventory agents and management tools that enumerate systems, and suppress them.
- Your own artefacts: ATT&CK lists organisation-specific values (domain names, share names, hostnames) as a tunable element. Raise severity when an unknown process queries those exact values.
- Mutex names: filter common benign names and focus on high-entropy or unusual names created by unsigned or newly seen binaries.
- ESXi: forward ESXi shell and hostd logs to your SIEM; see the ESXi Logs Detection Guide.
Why ATT&CK says do not mitigate
ATT&CK's mitigation for T1480 and both sub-techniques is M1055 Do Not Mitigate. Its reasoning is that preventive controls aimed at guardrails may stop them protecting unintended targets, and that efforts should instead go to preventing adversary tools from running earlier in the chain and to identifying subsequent malicious behaviour. In practice that means:
| Do not | Do instead |
|---|---|
| Try to fake or randomise host values to break guardrails | Block delivery and execution with application control, email and web filtering, and attack surface reduction rules |
| Pre-create known malware mutexes as an estate-wide "vaccine" without testing | Use known mutex names as detection indicators and hunt for them; treat any vaccine as a short-term, tested emergency measure |
| Rely on sandbox verdicts for targeted samples | Combine sandbox output with endpoint telemetry from the host where the sample was found |
| Assume a clean detonation means a benign file | Treat inert samples from targeted delivery as unresolved until the delivery context is understood |
Mutex vaccination is a judgement call. It can stop a specific ransomware family from running, but malware authors change names easily and some families ignore the mutex. We suggest using it only during an active outbreak, with the change recorded and removed afterwards.
Analysing guardrailed samples
- Capture context with the sample: record the hostname, domain, IP range, user and installed software of the host where it was found; guardrail values often match these.
- Detonate in a representative environment: use an analysis machine joined to a lab domain with your naming conventions, or configure the sandbox to present the victim's values. The Malware Sandbox Guide covers sandbox customisation.
- Read the checks statically: the strings and API calls used in the check reveal what values the author expected, which tells you who was targeted.
- Use endpoint telemetry: where the payload is keyed and cannot be decrypted, rebuild behaviour from EDR process, file and network events on the victim host.
- Share carefully: intelligence about a sample keyed to your environment can identify your organisation; strip identifying values before sharing externally.
Responding when guardrails point at you
- Escalate as targeted: a guardrail keyed to your domain, hostnames or IP ranges means the attacker already knew your environment; look for earlier reconnaissance and access.
- Scope by guardrail value: search for every host that matches the guardrail; those are the systems the payload would run on.
- Hunt the mutex or lock file: search the estate for the mutex name or lock file path to find other infected hosts.
- Check the allowlist logic: for ransomware with machine allowlists, the list may reveal hosts the attacker controls or wanted to preserve, such as their own staging systems.
- Preserve evidence: keep memory images, since keyed payloads may only exist decrypted in memory.
Where identity fits
Guardrails keyed to the joined AD domain or to user and logon context depend on information the attacker gathered through earlier discovery. Discovery from service accounts and other non-human identities that never normally enumerate the environment is a strong signal: a backup service account running domain and share discovery deserves an alert. ATT&CK's Windows analytics include logon events 4624 and 4648 for this reason. See the Identity Threat Hunting Guide.
Measuring it
- Discovery telemetry coverage: share of endpoints and ESXi hosts sending process, WMI and PowerShell logging needed by the analytics.
- Representative detonation: share of targeted-delivery samples analysed in an environment presenting your domain and naming conventions.
- Inert-sample follow-up: number of samples with no sandbox behaviour that were closed without endpoint telemetry review (target zero for targeted delivery).
- Mutex indicator hunts: time from a new mutex or lock file indicator to an estate-wide search.
- Discovery burst alerts: weekly count and true positive rate of discovery-burst alerts after tuning.
Common failure patterns
- Closing samples as benign because they did nothing: a keyed payload in a generic sandbox looks harmless.
- Discarding the host context: collecting the file but not the victim's hostname, domain and IP, which are needed to trigger it.
- No logging on ESXi: hypervisor discovery and selective deployment go unseen when ESXi logs stay on the host.
- Treating mutex vaccines as a control: leaving a vaccine in place and assuming the family is blocked after the author renames the mutex.
- Sharing keyed indicators unredacted: publishing guardrail values that identify your own organisation.
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| MITRE ATT&CK v20 | T1480, T1480.001, T1480.002; M1055; DET0562, DET0474, DET0132 | The technique, its sub-techniques, mitigation stance and detection strategies |
| MITRE ATT&CK v20 | T1497, T1622, T1082 System Information Discovery, T1016 System Network Configuration Discovery, T1614 System Location Discovery | Related evasion and the discovery the guardrail depends on |
| NIST SP 800-53 Rev. 5 | SI-3 Malicious Code Protection, SI-4 System Monitoring, AU-12 Audit Record Generation | Block execution earlier, monitor discovery, generate the records analytics need |
| NIST CSF 2.0 | DE.CM-09, DE.AE-02 | Monitor computing environments; analyse adverse events to understand associated activities |
Practitioner checklist
- Collect process, WMI-Activity and PowerShell script block logs on Windows, auditd on Linux, unified logs on macOS and shell and hostd logs on ESXi.
- Deploy the ATT&CK discovery-burst analytics with suppression for known admin and inventory tools.
- Alert when unknown processes query your own domain, share and hostname values.
- Hunt for known malware mutex names and lock file paths whenever new indicators arrive.
- Keep an analysis environment that presents your domain and naming conventions.
- Never close a targeted-delivery sample as benign on sandbox output alone.
- Escalate guardrails keyed to your environment as targeted intrusions.
- Redact your own environment values before sharing sample intelligence.
Standards and references
- MITRE ATT&CK: Execution Guardrails (T1480)
- MITRE ATT&CK: Environmental Keying (T1480.001)
- MITRE ATT&CK: Mutual Exclusion (T1480.002)
- MITRE ATT&CK: Do Not Mitigate (M1055)
- MITRE ATT&CK: Virtualization/Sandbox Evasion (T1497)
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: ATT&CK Stealth and Defense Impairment Tactics Guide · Malware Sandbox Guide · Malware Guide · ESXi Logs Detection Guide · Threat Hunting Guide