T1480

Execution Guardrails

Defense Evasion Last updated:

Adversaries may use execution guardrails to constrain execution or actions based on adversary-supplied and environment-specific conditions expected to be present on the target. Guardrails ensure a payload only executes against an intended target, reducing collateral damage from an adversary's campaign. Values used as guardrails include specific volume serial numbers, hostnames, Active Directory domain membership, IP addresses, the presence of specific files or processes, and specific command-line arguments. This technique is distinct from Virtualization/Sandbox Evasion (T1497): sandbox evasion avoids any analysis environment, while guardrails require a specific target environment to be confirmed before execution proceeds. Real-world examples include DEADEYE verifying volume serial number and hostname, Exbyte checking for a configuration file before completing execution, TONESHELL checking for ESET security processes (ekrn.exe, egui.exe) before injecting into waitfor.exe, BPFDoor using a PID mutex file at /var/run/haldrund.pid, RansomHub terminating if the machine appears on an allowlist, and Small Sieve requiring the literal keyword 'Platypus' as a command-line argument.

What is T1480 Execution Guardrails?

Execution Guardrails (T1480) maps to the Defense Evasion tactic — the adversary is trying to avoid being detected in MITRE ATT&CK.

This page provides production-ready detection logic for Execution Guardrails, covering the data sources and telemetry it touches: Process: Process Creation, Command: Command Execution, Microsoft Defender for Endpoint. The queries below are rated medium severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Defense Evasion
Technique
T1480 Execution Guardrails
Canonical reference
https://attack.mitre.org/techniques/T1480/
Microsoft Sentinel / Defender
kusto 
// T1480 Execution Guardrails — Environmental fingerprinting from suspicious execution contexts
// Detects processes performing target-validation checks (volume serial, hostname/domain, network identity,
// file presence, process presence) launched from LOLBin or script host parents.
// These behaviors are consistent with guardrail-enabled malware verifying it is on an intended target.
let ScriptHostsAndLolbins = dynamic([
    "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe",
    "regsvr32.exe", "msiexec.exe", "installutil.exe", "cmstp.exe",
    "powershell.exe", "pwsh.exe"
]);
let VolumeSerialPatterns = dynamic([
    "VolumeSerialNumber", "Win32_LogicalDisk",
    "vol c:", "vol d:", "vol e:", "fsutil volume"
]);
let DomainHostnamePatterns = dynamic([
    "Win32_ComputerSystem", "DNSDomain", "userdnsdomain",
    "logonserver", "nltest /domain_trusts", "nltest /dclist"
]);
let NetworkFingerprintPatterns = dynamic([
    "Win32_NetworkAdapterConfiguration", "MACAddress",
    "DefaultIPGateway", "Win32_NetworkAdapter"
]);
let FilePresencePatterns = dynamic([
    "if exist", "if not exist", "Test-Path",
    "haldrund.pid", "irc.pid"
]);
let ProcessPresencePatterns = dynamic([
    "ekrn.exe", "egui.exe",
    "tasklist /FI", "Get-Process -Name"
]);
DeviceProcessEvents
| where Timestamp > ago(24h)
| where InitiatingProcessFileName in~ (ScriptHostsAndLolbins)
    or (FileName in~ ("wmic.exe", "nltest.exe") and InitiatingProcessFileName in~ (ScriptHostsAndLolbins))
| where ProcessCommandLine has_any (VolumeSerialPatterns)
    or ProcessCommandLine has_any (DomainHostnamePatterns)
    or ProcessCommandLine has_any (NetworkFingerprintPatterns)
    or ProcessCommandLine has_any (FilePresencePatterns)
    or ProcessCommandLine has_any (ProcessPresencePatterns)
| extend GuardrailType = case(
    ProcessCommandLine has_any (VolumeSerialPatterns), "VolumeSerial",
    ProcessCommandLine has_any (DomainHostnamePatterns), "DomainOrHostname",
    ProcessCommandLine has_any (NetworkFingerprintPatterns), "NetworkIdentity",
    ProcessCommandLine has_any (FilePresencePatterns), "FilePresence",
    ProcessCommandLine has_any (ProcessPresencePatterns), "ProcessPresence",
    "Unknown"
)
| extend RiskScore = case(
    GuardrailType == "VolumeSerial", 3,
    GuardrailType == "ProcessPresence" and ProcessCommandLine has_any ("ekrn.exe", "egui.exe"), 3,
    GuardrailType in ("DomainOrHostname", "FilePresence", "ProcessPresence"), 2,
    1
)
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
         InitiatingProcessFileName, InitiatingProcessCommandLine,
         GuardrailType, RiskScore
| sort by RiskScore desc, Timestamp desc

Detects execution guardrail patterns where processes launched from suspicious parent executables (LOLBins, script hosts) query environment-specific properties such as volume serial numbers, domain/hostname, network adapter MAC address, file presence, or named process presence. These fingerprinting behaviors from script host or LOLBin parents are consistent with targeted malware validating the intended victim environment before releasing a payload. Volume serial checks and security-product process checks receive the highest risk score (3) due to near-zero legitimate use from these parent contexts. Domain/hostname and file presence checks score 2. Uses has_any for case-insensitive partial matching.

medium severity medium confidence

Data Sources

Process: Process Creation Command: Command Execution Microsoft Defender for Endpoint

Required Tables

DeviceProcessEvents

False Positives

  • Legitimate deployment scripts (SCCM, Group Policy) that check domain membership or hostname before applying configuration — typically parent process is svchost.exe or ccmexec.exe, not a LOLBin
  • Monitoring and inventory agents (Tanium, Qualys, SolarWinds) that enumerate network adapter properties or system info — whitelist by exact parent process name
  • IT automation tools (PDQ Deploy, Altiris) that verify target environment before running installation packages
  • Developer environment setup scripts that check for specific environments (dev/staging/prod) using hostname or domain name
  • Backup software (Veeam, Acronis) that queries volume serial numbers for backup source identification — typically runs as a known service account

Sigma rule & cross-platform mapping

The detection logic for Execution Guardrails (T1480) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource: 

logsource:
  category: process_creation
  product: windows

Browse the community-maintained Sigma rules for this technique:

SigmaHQ rules for T1480 Sigma rules on detection.fyi

Platform-specific guides for T1480

Detect in Microsoft Sentinel (KQL) Detect in Splunk (SPL) Detect in Elastic Security (Elastic) Detect in IBM QRadar (QRadar) Detect in Sumo Logic CSE (Sumo) Detect in Google Chronicle (YARA-L) Detect in CrowdStrike LogScale (LogScale)
Last updated: 2026-04-13 Research depth: deep
References (9)

Testing Methodology

Validate this detection against 5 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Volume Serial Number Enumeration via WMIC

    Expected signal: Sysmon Event ID 1: Process Create with Image containing wmic.exe, CommandLine containing 'VolumeSerialNumber' and 'Win32_LogicalDisk'. Security Event ID 4688 (if command-line auditing enabled). WMI Activity Event ID 5861 in Microsoft-Windows-WMI-Activity/Operational showing the Win32_LogicalDisk query. Defender MDE: DeviceProcessEvents row with FileName=wmic.exe.

  2. Test 2Hostname and Domain Membership Check via PowerShell WMI

    Expected signal: Sysmon Event ID 1: Process Create with Image=powershell.exe, CommandLine containing 'Win32_ComputerSystem'. PowerShell ScriptBlock Log Event ID 4104 showing the WMI query in clear text. WMI Activity Event ID 5861 for the Win32_ComputerSystem query with property names Name, Domain, DNSDomain.

  3. Test 3File Presence Guardrail Check via CMD

    Expected signal: Sysmon Event ID 1: Process Create with Image=cmd.exe, CommandLine containing 'if exist'. Sysmon Event ID 11: File Create for the %TEMP%\df00tech-guard.cfg file. Security Event ID 4688 showing the full command with conditional logic.

  4. Test 4Security Product Process Check via Tasklist

    Expected signal: Sysmon Event ID 1: Two process creation events — cmd.exe spawning tasklist.exe (CommandLine containing 'IMAGENAME eq ekrn.exe') and findstr.exe. Security Event ID 4688 for tasklist.exe with the /FI IMAGENAME filter argument visible in command-line audit.

  5. Test 5Linux PID File Mutex Guardrail

    Expected signal: Linux auditd SYSCALL records: open()/creat() syscall on /var/run/test_guardrail_df00tech.pid (type=SYSCALL, syscall=open or openat). Syslog entries showing bash process activity. If MDE for Linux is deployed: DeviceFileEvents row with FileName=test_guardrail_df00tech.pid, FolderPath=/var/run/, InitiatingProcessFileName=bash.

Response Playbook

Triage

  1. Identify the specific guardrail type detected: volume serial check (RiskScore 3 — rare legitimate use), security process presence check for known AV products like ESET ekrn.exe/egui.exe (RiskScore 3 — strong indicator), domain/hostname check (RiskScore 2), file presence check (RiskScore 2), or network identity check (RiskScore 1). Higher scores warrant faster escalation.
  2. Examine the full parent process chain — what spawned the process performing the environmental check? A script host (wscript.exe, mshta.exe, cscript.exe) or LOLBin (rundll32.exe, regsvr32.exe) launching wmic.exe to query VolumeSerialNumber is a strong indicator of malicious activity with essentially no legitimate baseline.
  3. Check the account context — is the executing account a service account, domain admin, or standard user? Standard users running wmic VolumeSerialNumber queries from a script host parent are highly anomalous. Service accounts with change tickets for deployment activity are lower priority.
  4. Review the process behavior timeline: did the fingerprinting check occur within 30–120 seconds before any suspicious child process creation, download cradle, lateral movement command, or file write to temp/AppData? Temporal proximity to follow-on execution is the key escalation gate.
  5. Search for the full process tree — what did the checking process do after the guardrail evaluation? Look for follow-on execution of payloads, encoded PowerShell, LOLBin abuse chains, or privilege escalation attempts. Use DeviceProcessEvents where InitiatingProcessId matches the guardrail process.
  6. Correlate with recent delivery vectors on the same endpoint: check for recent email attachment opens (OfficeActivity, DeviceFileEvents for .doc/.xls/.one files), USB mount events, or web downloads shortly before the alert to identify the initial access vector.

Containment

  1. If the guardrail check was followed by payload execution, C2 beaconing, or credential access activity, immediately isolate the endpoint using EDR network isolation or VLAN reassignment to prevent lateral movement while preserving the device for forensics.
  2. If a malicious script or dropper binary was identified (parent of the guardrail check), quarantine the file hash across all endpoints via EDR policy and block it at the AV/EDR management console before broader propagation occurs.
  3. If a configuration file served as the guardrail trigger (Exbyte pattern — checking for config.dat before executing), preserve and collect that file as a forensic artifact before any remediation; it may contain targeting configuration or encryption keys.
  4. If the guardrail check preceded security product process enumeration (TONESHELL pattern), treat the endpoint as fully compromised: the malware has already assessed the security posture and may have modified its execution path accordingly.
  5. Block any C2 domains or IPs identified in follow-on network connections at the perimeter firewall, DNS sinkhole, and proxy deny-list. Generate threat intel from observed destinations to hunt across the broader environment.

Evidence Collection

  1. Process creation events — Sysmon Event ID 1 (or Security Event ID 4688 with command-line auditing enabled) for the complete parent-child process chain around the guardrail check and any follow-on activity.
  2. WMI activity logs — Microsoft-Windows-WMI-Activity/Operational Event IDs 5857, 5860, 5861 for any WMI queries used to check volume serial number (Win32_LogicalDisk), hostname, or domain (Win32_ComputerSystem). Event ID 5858 records WMI errors which can indicate failed guardrail checks.
  3. PowerShell logs — Microsoft-Windows-PowerShell/Operational Event IDs 4103 (Module Logging) and 4104 (ScriptBlock Logging) for full deobfuscated script content if PowerShell performed the fingerprinting. Event ID 4104 will show the decoded Win32_ComputerSystem or GetVolumeInformation call.
  4. File system artifacts — any configuration files, PID files, or mutex files referenced in the guardrail logic (e.g., /var/run/haldrund.pid on Linux, /Users/Shared/irc.pid on macOS, application-specific .dat/.cfg files in %TEMP% or %APPDATA%).
  5. Network connection events — Sysmon Event ID 3 or DeviceNetworkEvents for connections made after the guardrail check passed, indicating payload delivery or C2 communication initiation.
  6. Memory artifacts — if the process is still running, capture a process memory dump using ProcDump or EDR forensics to recover the full guardrail comparison logic and expected environment values hardcoded in the binary.
  7. Prefetch files — C:\Windows\Prefetch\WMIC.EXE-*.pf, POWERSHELL.EXE-*.pf for execution timestamps and evidence of which DLLs and resources were accessed during the guardrail check.
  8. Linux auditd — /var/log/audit/audit.log SYSCALL records for open(), read(), stat() calls against /etc/hostname, /etc/machine-id, and /var/run/*.pid; use ausearch -sc open to filter for file access events.

Escalation Criteria

  • ! Volume serial number query (Win32_LogicalDisk VolumeSerialNumber or 'vol C:') from any script host or LOLBin parent — this has virtually no legitimate use in standard enterprise workflows and is a near-certain indicator of targeted malware.
  • ! Security product process check specifically targeting named AV/EDR executables (ekrn.exe, egui.exe, MsMpEng.exe, SentinelAgent.exe) before a follow-on execution step — directly replicates TONESHELL behavior indicating deliberate security tool awareness.
  • ! Guardrail fingerprint check immediately followed (within 60 seconds) by a download cradle, process injection (Sysmon Event ID 8), credential access tool, or lateral movement command.
  • ! Same fingerprinting pattern detected across multiple endpoints within a short time window — suggests automated propagation, a worm-like component, or concurrent operator activity across the environment.
  • ! Known BPFDoor/LightSpy guardrail file paths detected (/var/run/haldrund.pid, /Users/Shared/irc.pid) — these are specific IOCs with no legitimate use.
  • ! Fingerprinting activity under a SYSTEM or domain admin account that has no corresponding authorized change ticket — elevated privilege combined with guardrail behavior indicates post-exploitation activity.

Investigation Guide

Forensic Artifacts

  • > WMI Execution: Microsoft-Windows-WMI-Activity/Operational Event IDs 5857–5861 — records queries for Win32_LogicalDisk (VolumeSerialNumber), Win32_ComputerSystem (Name, Domain, DNSDomain), Win32_NetworkAdapterConfiguration; Event 5858 records failed queries indicating a guardrail that did not pass
  • > Registry: HKLM\SYSTEM\CurrentControlSet\Services\Disk\Enum — volume device GUIDs that correlate with serial number checks; HKLM\SYSTEM\CurrentControlSet\Control\ComputerName\ComputerName for hostname value malware may compare against
  • > File System (Windows): Application-specific guardrail files in %TEMP%, %APPDATA%, %PROGRAMDATA% — anomalous .dat, .cfg, .ini files with creation timestamps matching the suspected intrusion window
  • > File System (Linux): /var/run/*.pid and /tmp/*.lock files created by non-system processes; /proc/<pid>/cmdline for running processes; /etc/machine-id and /etc/hostname as common read targets for host fingerprinting
  • > File System (macOS): /Users/Shared/irc.pid (LightSpy mutex), /private/var/run/*.pid for unexpected process mutex files
  • > Prefetch: C:\Windows\Prefetch\WMIC.EXE-*.pf, NLTEST.EXE-*.pf, HOSTNAME.EXE-*.pf showing execution timestamps and DLL load order for guardrail-related binaries
  • > Memory Forensics: Strings in malware process memory will contain the expected hostname, volume serial number, or domain name as a hardcoded literal comparison target — use 'strings' or Volatility on a memory dump
  • > Event Log: Security Event ID 4688 with ProcessCreationIncludeCmdLine=1 (command-line auditing) showing wmic.exe or powershell.exe arguments used for fingerprinting; Event ID 4104 PowerShell ScriptBlock for decoded guardrail logic

Tuning Guidance

Begin by baselining which processes in your environment legitimately query volume serial numbers — typically backup agents (Veeam, Acronis, BackupExec running as service accounts) and disk management utilities. Allowlist these by parent process name and service account identity rather than broad volume serial suppression. Domain/hostname checks are far more common in deployment scripts: allowlist exact parent process and command-line combinations for SCCM (parent ccmexec.exe), Ansible (parent python3), and similar tools. For process presence checks, the key signal is whether the queried process is a security product (ekrn.exe, egui.exe, MsMpEng.exe) — any script host querying for AV processes should be treated as high confidence with minimal tuning. On Linux, build an allowlist of expected PID file paths (/var/run/nginx.pid, /var/run/sshd.pid, etc.) and filter known daemon names from the hunting query. Consider pairing T1480 alerts with T1082 (System Information Discovery) alerts: two detections on the same host within a 5-minute window is substantially higher confidence than either signal alone. Enable WMI activity logging (Microsoft-Windows-WMI-Activity/Operational) if not already active — it provides richer query context than process creation events alone for WMI-based fingerprinting.

Hunting Queries

Hunt for volume serial number enumeration by non-system accounts. Volume serial number queries are nearly exclusive to backup software and targeted malware in enterprise environments — they are not routine admin activity. Low event counts (1–3) are more suspicious than high counts because guardrail checks are one-time per-infection events, not recurring administrative scripts.

Hunting — KQL
kql 
// Hunt: Volume serial number enumeration by non-system accounts — extremely rare legitimate use
// Targeted guardrail checks are typically one-off events (count=1), not recurring admin scripts
DeviceProcessEvents
| where Timestamp > ago(7d)
| where (FileName =~ "wmic.exe" and ProcessCommandLine has_any ("VolumeSerialNumber", "Win32_LogicalDisk"))
    or (FileName in~ ("powershell.exe", "pwsh.exe")
        and ProcessCommandLine has_any ("VolumeSerialNumber", "GetVolumeInformation", "Win32_LogicalDisk"))
    or (FileName =~ "cmd.exe" and ProcessCommandLine has "vol " and ProcessCommandLine matches regex @"(?i)vol\s+[a-z]:")
| where AccountName !in~ ("SYSTEM", "LOCAL SERVICE", "NETWORK SERVICE")
| summarize
    EventCount = count(),
    UniqueDevices = dcount(DeviceName),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp),
    SampleCommands = make_set(ProcessCommandLine, 5),
    ParentProcesses = make_set(InitiatingProcessFileName, 5)
  by AccountName, FileName
| sort by EventCount asc
| where EventCount <= 3  // Low counts indicate targeted one-time checks, not recurring admin scripts
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
  ((Image="*\\wmic.exe" (CommandLine="*VolumeSerialNumber*" OR CommandLine="*Win32_LogicalDisk*"))
  OR (Image="*\\powershell.exe" (CommandLine="*VolumeSerialNumber*" OR CommandLine="*GetVolumeInformation*"))
  OR (Image="*\\cmd.exe" CommandLine="*vol [a-zA-Z]:*"))
  NOT (User="NT AUTHORITY\\SYSTEM" OR User="*LOCAL SERVICE*" OR User="*NETWORK SERVICE*")
| stats count as EventCount, dc(host) as UniqueDevices,
        earliest(_time) as FirstSeen, latest(_time) as LastSeen,
        values(CommandLine) as Commands, values(ParentImage) as Parents
  by User, Image
| where EventCount <= 3
| sort EventCount asc

Hunt for the complete guardrail attack sequence: an environmental fingerprint check followed within 2 minutes by a suspicious execution event (LOLBin, encoded PowerShell, download cradle). This temporal correlation between the identify step and the execute step is the defining behavioral pattern of guardrail-enabled malware and is largely distinct from normal administrative activity.

Hunting — KQL
kql 
// Hunt: Environmental fingerprint check followed within 2 minutes by suspicious execution
// This temporal sequence (identify → execute) is the core guardrail behavioral pattern
let FingerprintEvents = DeviceProcessEvents
| where Timestamp > ago(7d)
| where (FileName =~ "wmic.exe"
        and ProcessCommandLine has_any ("VolumeSerialNumber", "Win32_LogicalDisk", "Win32_ComputerSystem", "DNSDomain"))
    or (FileName in~ ("powershell.exe", "pwsh.exe")
        and ProcessCommandLine has_any ("VolumeSerialNumber", "GetVolumeInformation", "Win32_ComputerSystem", "DNSDomain"))
    or (FileName =~ "nltest.exe" and ProcessCommandLine has_any ("/domain_trusts", "/dclist"))
| project FingerprintTime = Timestamp, DeviceName, AccountName,
         FingerprintProcess = FileName, FingerprintCmd = ProcessCommandLine;
let SuspiciousExecution = DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("mshta.exe", "regsvr32.exe", "rundll32.exe", "cmstp.exe",
                      "installutil.exe", "wscript.exe", "cscript.exe")
    or (FileName in~ ("powershell.exe", "pwsh.exe")
        and ProcessCommandLine has_any ("-EncodedCommand", "-enc ", "IEX", "DownloadString", "DownloadFile"))
| project ExecTime = Timestamp, DeviceName, AccountName,
         ExecProcess = FileName, ExecCmd = ProcessCommandLine;
FingerprintEvents
| join kind=inner SuspiciousExecution on DeviceName, AccountName
| where ExecTime > FingerprintTime and ExecTime < FingerprintTime + 2m
| project FingerprintTime, ExecTime, DeviceName, AccountName,
         FingerprintProcess, FingerprintCmd, ExecProcess, ExecCmd
| sort by FingerprintTime desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
  ((Image="*\\wmic.exe" (CommandLine="*VolumeSerialNumber*" OR CommandLine="*Win32_ComputerSystem*" OR CommandLine="*DNSDomain*"))
  OR (Image="*\\powershell.exe" (CommandLine="*VolumeSerialNumber*" OR CommandLine="*DNSDomain*"))
  OR (Image="*\\nltest.exe" (CommandLine="*/domain_trusts*" OR CommandLine="*/dclist*"))
  OR Image="*\\mshta.exe" OR Image="*\\regsvr32.exe" OR Image="*\\rundll32.exe"
  OR (Image="*\\powershell.exe" (CommandLine="*-EncodedCommand*" OR CommandLine="*IEX*" OR CommandLine="*DownloadString*")))
| eval event_type=case(
    match(lower(Image), "(wmic|nltest)\\.exe$") OR (match(lower(Image), "powershell\\.exe$") AND match(lower(CommandLine), "(volumeserialnumber|dnsdomain|win32_computer)")), "fingerprint",
    match(lower(Image), "(mshta|regsvr32|rundll32)\\.exe$") OR (match(lower(Image), "powershell\\.exe$") AND match(lower(CommandLine), "(-encodedcommand|iex|downloadstring)")), "execution",
    true(), "other")
| where event_type != "other"
| bin _time span=2m
| stats values(event_type) as EventTypes, values(CommandLine) as CMDs, values(Image) as Images, count by host, User, _time
| where mvcount(EventTypes) > 1 AND mvfind(EventTypes, "fingerprint") >= 0 AND mvfind(EventTypes, "execution") >= 0
| sort - _time

Hunt for PID file mutex creation by non-system processes on Linux and macOS. BPFDoor creates /var/run/haldrund.pid and LightSpy creates /Users/Shared/irc.pid as execution guardrails to prevent duplicate instances. Unexpected executables (not recognized system daemons) creating .pid or .lock files in standard runtime directories are a strong IOC. The known guardrail file names are treated as high-severity immediate escalation triggers.

Hunting — KQL
kql 
// Hunt: Linux/macOS PID file mutex creation by non-system processes
// BPFDoor uses /var/run/haldrund.pid; LightSpy uses /Users/Shared/irc.pid as execution guardrails
DeviceFileEvents
| where Timestamp > ago(7d)
| where (FolderPath has "/var/run/" or FolderPath has "/tmp/" or FolderPath has "/Users/Shared/")
    and (FileName endswith ".pid" or FileName endswith ".lock")
| where InitiatingProcessFileName !in~ (
    "systemd", "init", "upstart", "launchd", "crond", "cron",
    "apt", "apt-get", "dpkg", "yum", "dnf", "brew",
    "nginx", "apache2", "httpd", "sshd", "rsyslogd",
    "NetworkManager", "dhclient", "auditd"
)
| extend IsKnownGuardrailFile = FileName in~ ("haldrund.pid", "irc.pid")
| extend Severity = iff(IsKnownGuardrailFile, "High", "Medium")
| project Timestamp, DeviceName, AccountName, FileName, FolderPath,
         InitiatingProcessFileName, InitiatingProcessCommandLine,
         IsKnownGuardrailFile, Severity
| sort by IsKnownGuardrailFile desc, Timestamp desc
Hunting — SPL
spl 
index=linux_audit sourcetype=linux_audit
| rex field=_raw "name=\"(?P<file_path>[^\"]+\\.(?:pid|lock))\""
| where isnotnull(file_path)
  AND (match(file_path, "^/var/run/") OR match(file_path, "^/tmp/") OR match(file_path, "^/Users/Shared/"))
| rex field=_raw "exe=\"(?P<exe_path>[^\"]+)\""
| eval is_known_guardrail=if(match(file_path, "(haldrund\\.pid|irc\\.pid)"), 1, 0)
| where NOT match(exe_path, "/(systemd|init|crond?|sshd|nginx|apache2?|rsyslogd?|NetworkManager|dhclient|auditd|journald)$")
| eval severity=if(is_known_guardrail=1, "High", "Medium")
| stats count, values(file_path) as PidFiles, values(exe_path) as Executables
  by host, is_known_guardrail, severity
| sort - is_known_guardrail, - count

Atomic Red Team Tests

Test 1 Volume Serial Number Enumeration via WMIC
windows

Simulates the DEADEYE malware guardrail check that queries the C: drive volume serial number before executing the payload. DEADEYE uses this to confirm it is running on the intended target system. The wmic query against Win32_LogicalDisk for VolumeSerialNumber generates both a process creation event and a WMI activity audit event.

Command

powershell 
wmic logicaldisk where "DeviceID='C:'" get VolumeSerialNumber

Expected Telemetry

Sysmon Event ID 1: Process Create with Image containing wmic.exe, CommandLine containing 'VolumeSerialNumber' and 'Win32_LogicalDisk'. Security Event ID 4688 (if command-line auditing enabled). WMI Activity Event ID 5861 in Microsoft-Windows-WMI-Activity/Operational showing the Win32_LogicalDisk query. Defender MDE: DeviceProcessEvents row with FileName=wmic.exe.

Expected Detection

KQL: matches VolumeSerialPatterns, GuardrailType='VolumeSerial', RiskScore=3. SPL: VolumeSerialCheck=1, RiskScore=3. Highest-confidence guardrail signal — volume serial queries from non-backup processes are anomalous.

Test 2 Hostname and Domain Membership Check via PowerShell WMI
windows

Simulates the DEADEYE and CHIMNEYSWEEP guardrail pattern of using PowerShell WMI to verify both the hostname and domain of the victim before proceeding. The combined query checks Win32_ComputerSystem.Name and Win32_ComputerSystem.Domain in a single call — the same interface used by multiple targeted malware families to perform identity verification.

Command

powershell 
powershell.exe -NoProfile -Command "$cs = Get-WmiObject Win32_ComputerSystem; Write-Output ('Host: ' + $cs.Name + ' | Domain: ' + $cs.Domain + ' | DNSDomain: ' + $cs.DNSDomain)"

Expected Telemetry

Sysmon Event ID 1: Process Create with Image=powershell.exe, CommandLine containing 'Win32_ComputerSystem'. PowerShell ScriptBlock Log Event ID 4104 showing the WMI query in clear text. WMI Activity Event ID 5861 for the Win32_ComputerSystem query with property names Name, Domain, DNSDomain.

Expected Detection

KQL: matches DomainHostnamePatterns, GuardrailType='DomainOrHostname', RiskScore=2. SPL: DomainHostnameCheck=1, RiskScore=2. If PowerShell itself was spawned from a suspicious parent (mshta.exe, wscript.exe), the parent-chain context elevates this to a high-confidence alert.

Test 3 File Presence Guardrail Check via CMD
windows

Simulates the Exbyte ransomware guardrail that checks for the presence of a configuration file before completing execution. Uses the classic cmd.exe 'if exist' conditional — one of the most common file-based guardrail implementations in malware. The test creates a temporary guardrail marker file, checks for it using the malware pattern, and reports the result.

Command

powershell 
cmd.exe /c "echo guardrail_marker > %TEMP%\df00tech-guard.cfg && if exist %TEMP%\df00tech-guard.cfg (echo GUARDRAIL_PASSED_EXECUTING_PAYLOAD) else (echo GUARDRAIL_FAILED_TERMINATING)"

Cleanup

powershell 
cmd.exe /c del %TEMP%\df00tech-guard.cfg 2>nul

Expected Telemetry

Sysmon Event ID 1: Process Create with Image=cmd.exe, CommandLine containing 'if exist'. Sysmon Event ID 11: File Create for the %TEMP%\df00tech-guard.cfg file. Security Event ID 4688 showing the full command with conditional logic.

Expected Detection

KQL: matches FilePresencePatterns ('if exist'), GuardrailType='FilePresence', RiskScore=2. SPL: FilePresenceCheck=1, RiskScore=2. Note: 'if exist' is common in batch scripts — correlation with a suspicious parent process (wscript.exe, mshta.exe) is required for high-confidence alerting.

Test 4 Security Product Process Check via Tasklist
windows

Simulates the TONESHELL malware behavior that checks for ESET security processes (ekrn.exe, egui.exe) before deciding its execution path — TONESHELL directly injects into waitfor.exe only when these AV processes are absent. Uses tasklist /FI with the IMAGENAME filter, the same technique used by guardrail-aware malware to detect security tools before committing to a code injection path.

Command

powershell 
cmd.exe /c "tasklist /FI \"IMAGENAME eq ekrn.exe\" 2>NUL | findstr /I ekrn.exe && echo AV_DETECTED_TAKING_ALTERNATE_PATH || echo AV_NOT_FOUND_PROCEEDING_WITH_INJECTION"

Expected Telemetry

Sysmon Event ID 1: Two process creation events — cmd.exe spawning tasklist.exe (CommandLine containing 'IMAGENAME eq ekrn.exe') and findstr.exe. Security Event ID 4688 for tasklist.exe with the /FI IMAGENAME filter argument visible in command-line audit.

Expected Detection

KQL: matches ProcessPresencePatterns ('ekrn.exe', 'tasklist /FI'), GuardrailType='ProcessPresence', RiskScore=3. SPL: ProcessPresenceCheck=1 with ekrn.exe match, RiskScore=3. Any script host or LOLBin parent spawning tasklist to check for named AV processes should be immediately escalated.

Test 5 Linux PID File Mutex Guardrail
linux

Simulates BPFDoor's mutex mechanism that creates a PID file at /var/run/haldrund.pid to prevent duplicate execution. The script checks whether the PID file already exists (another instance running — guardrail fails) and exits, or writes its own PID if not found (guardrail passes — execution proceeds). This directly replicates BPFDoor's self-limiting behavior.

Command

bash 
PIDFILE=/var/run/test_guardrail_df00tech.pid; if [ -f "$PIDFILE" ]; then echo 'GUARDRAIL_FAILED: already running, exiting'; exit 1; fi; echo $$ > "$PIDFILE"; echo "GUARDRAIL_PASSED: PID $$ written, proceeding with execution"; sleep 3; rm -f "$PIDFILE"

Cleanup

bash 
rm -f /var/run/test_guardrail_df00tech.pid

Expected Telemetry

Linux auditd SYSCALL records: open()/creat() syscall on /var/run/test_guardrail_df00tech.pid (type=SYSCALL, syscall=open or openat). Syslog entries showing bash process activity. If MDE for Linux is deployed: DeviceFileEvents row with FileName=test_guardrail_df00tech.pid, FolderPath=/var/run/, InitiatingProcessFileName=bash.

Expected Detection

Matches Linux PID file hunting query in DeviceFileEvents. The known guardrail path 'haldrund.pid' would trigger IsKnownGuardrailFile=true for immediate high-severity escalation. For this test file, alert fires based on unexpected .pid file creation in /var/run/ by a non-system process.

Related Detections

Tactic Hub

TA0005Defense Evasion

Sub-techniques (2)

Related Techniques

T1480.001Environmental KeyingT1480.002Mutual ExclusionT1497Virtualization/Sandbox EvasionT1497.001System ChecksT1082System Information DiscoveryT1016System Network Configuration DiscoveryT1057Process DiscoveryT1083File and Directory DiscoveryT1033System Owner/User DiscoveryT1018Remote System Discovery

Same Tactic: Defense Evasion

Popular Detections