Debugger Evasion (T1622) sits in both the Stealth and Discovery tactics, on Windows, Linux and macOS. Adversaries use various means to detect and avoid debuggers, which defenders use to trace and analyze how malware runs.
This one is mostly an analyst problem. If your malware analysis or sandbox pipeline is trusted to explain what a sample does, evasion can quietly make it say nothing.
How attackers use it
MITRE explains that malware may change its behavior depending on whether it finds artifacts that indicate a debugged environment. If a debugger is detected, the malware may disengage from the victim, hide its core functions, or hold back secondary payloads. This resembles Virtualization/Sandbox Evasion (T1497).
The checks vary. MITRE lists these:
- Windows: Native API calls such as IsDebuggerPresent and NtQueryInformationProcess, or checking the BeingDebugged flag in the Process Environment Block.
- Linux: reading /proc/self/status for the TracerPID field, which shows whether the process is being traced.
- Other signals: hardware breakpoints, interrupt opcodes, timing checks, and whether an exception is swallowed by an attached debugger. Structured Exception Handling can also be used, by throwing an exception and seeing whether the process is suspended.
Examples listed on the page include Black Basta's dropper checking system flags, CPU registers and process timing, AsyncRAT using CheckRemoteDebuggerPresent, Lumma Stealer looking for window titles that contain names of well known debuggers, Raspberry Robin using ThreadHideFromDebugger, and Mustang Panda embedding debug strings with messages meant to distract analysts.
How to detect it
MITRE's analytics by platform:
- Windows: suspicious use of IsDebuggerPresent and NtQueryInformationProcess, processes checking the BeingDebugged flag, and bursts of OutputDebugString calls that may indicate attempts to flood a debugger.
- Linux: reads of /proc/self/status that query TracerPID, and processes that deliberately trigger exceptions to see whether a debugger handles them.
- macOS and Linux: suspicious calls to sysctl or ptrace used to learn whether a process is being debugged.
On a normal production endpoint these API calls will rarely show up in your logs, because they are in-process. They are visible to endpoint tools that watch API behavior and to the sandboxes you run samples in.
How to reduce the risk
MITRE does not list a mitigation for this technique. Its purpose is to frustrate analysis, so the response is analytic. Compare behavior across environments: a sample that does nothing under a debugger but acts in a plain virtual machine tells you something. Keep more than one analysis setup, hide analysis tooling where you can, and give extra weight to a sample whose first action is to look for tools.
Quick check
What does TracerPID tell a Linux process?
Whether the process is currently being traced. MITRE says malware can read it from /proc/self/status to detect dynamic analysis.
Which two tactics does this technique belong to?
Stealth and Discovery.
