Home/ATT&CK Technique/Debugger Evasion
ATT&CK Technique

Debugger Evasion

T1622 · stealth, discovery

Adversaries may employ various means to detect and avoid debuggers. Debuggers are typically used by defenders to trace and/or analyze the execution of potential malware payloads. Debugger evasion may include changing behaviors based on the results of the checks for the presence of artifacts indicative of a debugged environment.

Similar to Virtualization/Sandbox Evasion, if the adversary detects a debugger, they may alter their malware to disengage from the victim or conceal the core functions of the implant. They may also search for debugger artifacts before dropping secondary or additional payloads. Specific checks will vary based on the target and/or adversary.

On Windows, this may involve Native API function calls such as IsDebuggerPresent() and NtQueryInformationProcess(), or manually checking the BeingDebugged flag of the Process Environment Block (PEB). On Linux, this may involve querying /proc/self/status for the TracerPID field, which indicates whether or not the process is being traced by dynamic analysis tools. Other checks for debugging artifacts may also seek to enumerate hardware breakpoints, interrupt assembly opcodes, time checks, or measurements if exceptions are raised in the current process (assuming a present debugger would “swallow” or handle the potential error).

Malware may also leverage Structured Exception Handling (SEH) to detect debuggers by throwing an exception and detecting whether the process is suspended. SEH handles both hardware and software expectations, providing control over the exceptions including support for debugging. If a debugger is present, the program’s control will be transferred to the debugger, and the execution of the code will be suspended.

If the debugger is not present, control will be transferred to the SEH handler, which will automatically handle the exception and allow the program’s execution to continue. Adversaries may use the information learned from these debugger checks during automated discovery to shape follow-on behaviors. Debuggers can also be evaded by detaching the process or flooding debug logs with meaningless data via messages produced by looping Native API function calls such as OutputDebugStringW().

LinuxmacOSWindows
◆

Actors Using This

3
israel_private_sector_mobile_forensics_cyber_mercenaryCellebrite
north_koreaLazarus Group
indiaSideWinder
◈

Likely Attack Path

Techniques the same actors pair with this one distinctively - those showing up among actors who use this technique noticeably more than across all actors (lift > 1.15), grouped by kill-chain phase. The × is that lift multiplier; the shared-actor count is in the tooltip. A near-universal technique pairs with everything at baseline, so its list is short by design.
resource-development earlier
T1584 · Compromise Infrastructure ×1.27T1585 · Establish Accounts ×1.21
execution earlier
T1203 · Exploitation for Client Execution ×1.43
collection later
T1560 · Archive Collected Data ×2.12T1056.001 · Keylogging ×1.62T1074 · Data Staged ×1.52T1056 · Input Capture ×1.34
other same
T1564 · Hide Artifacts ×2.98T1218 · System Binary Proxy Execution ×1.16
▸

Atomic Tests

1
Executable Atomic Red Team test cases for exercising this technique in a lab. Copy a command, run it on the listed platform, confirm your detections fire.
powershellelevatedwindowsDetect a Debugger Presence in the Machine
Detecting a running debugger process or if the debugger is attached to a process via PowerShell
# Check for common debugger processes
$debuggerProcesses = Get-Process | Where-Object { $_.ProcessName -match "dbg" -or $_.ProcessName -match "debug" }
# Check for debugging flags
$debuggingFlags = [System.Diagnostics.Debugger]::IsAttached
◈

Detection Coverage

2/6 layers
Coverage across standard detection surfaces. Rows marked none have no rule of that type mapped. Some are real blind spots worth closing; others are simply not applicable to this technique (e.g. YARA matches malware files, not network behaviour).
Behavioral / log (Sigma) 1
Analytics (MITRE CAR) none
Runtime / container (Falco) 1
File / malware (YARA) none
Network (Suricata/Snort) none
Vuln scan (Nuclei) none
◈

Falco Runtime Rules

1
Container / Linux runtime detections that fire on this technique.
NOTICEPTRACE anti-debug attempt
Detect usage of the PTRACE system call with the PTRACE_TRACEME argument, indicating a program actively attempting to avoid debuggers attaching to the process. This behavior is typically indicative of malware activity. Read more about PTRACE in the "PTRACE attached to process" rule.
view condition
evt.type=ptrace and evt.arg.request contains PTRACE_TRACEME and proc_name_exists
▣

Comply & Defend

NIST 800-53AC-03, AC-04, CA-07, CM-02, CM-06, CM-07, CM-08, SC-07, SC-08, SC-23, SC-46, SI-03, SI-04, SI-10, SI-15
Intelligence Graph · click any node to traverse
CVETechnique ActorTool Family
drag to reposition · click any node to traverse · button top-right enlarges
External lookups - second-class, for what we don’t hold ourselves
MITRE ATT&CKAtomic Red Teamcar (MITRE)
Vulnerabilities
CISA KEV catalog
CWE weaknesses
CAPEC attack patterns
Package vulnerabilities
Threat intelligence
Threat actors
Tools & malware
ATT&CK techniques
IOCs
Detection & defense
Sigma rules
YARA rules
Atomic Red Team tests
D3FEND countermeasures
Compliance
NIST 800-53
ISO 27001:2022
SOC 2 TSC
PCI-DSS v4.0
CIS Controls v8.1
About
All capabilities
Live statistics
Data sources
Privacy policy
Terms of service
threatengine.sh  ·  Open-source threat intelligence platform  ·  100+ authoritative sources  ·  Every fact traces to its origin