MITRE ATT&CK T1622 Debugger Evasion: Detecting Evasion

Malware that checks for a debugger before it acts will show your analysts a harmless program and keep its real behaviour for machines nobody is watching. MITRE ATT&CK T1622 Debugger Evasion describes adversaries detecting and avoiding debuggers, then changing behaviour: exiting, hiding core functions, or holding back secondary payloads. In ATT&CK v20 it belongs to two tactics, Stealth (TA0005) and Discovery (TA0007), on Windows, Linux and macOS. ATT&CK lists no preventive mitigation, so the defensive value lies in two places: detection of the checks on real endpoints, and analysis practice that does not take a quiet sample at face value. This guide is for SOC analysts, detection engineers and malware analysts. For the companion technique that checks for virtual machines and sandboxes, see MITRE ATT&CK T1497 Virtualization/Sandbox Evasion; for analysis tooling, the Ghidra for Malware Analysis Guide.

Key takeaways

• Evasion and discovery in one. ATT&CK places T1622 under both Stealth and Discovery because the check results can shape what the malware does next, not only whether it hides.
• The checks are ordinary API calls. IsDebuggerPresent, CheckRemoteDebuggerPresent and NtQueryInformationProcess are documented Windows functions also used by legitimate software, so a single call is not a detection.
• It is everywhere in commodity malware. ATT&CK v20 lists loaders, stealers, RATs and ransomware including Lumma Stealer, Pikabot, DarkGate, AsyncRAT, PlugX, Raspberry Robin and LockBit 3.0.
• Detection works on combinations. Debugger checks next to analysis-tool enumeration, sandbox checks, unbacked memory execution or an early exit are far more telling than any one call.
• A clean sandbox verdict is not proof. If a sample checks for debuggers and then does little, treat the quiet run as a finding and escalate to deeper analysis.

What T1622 covers

ATT&CK version 2.0 of the technique (last modified 11 September 2026) describes checks for artefacts of a debugged environment, and behaviour changes based on the results. The checks fall into a few families:

Check Point Research's Anti-Debug encyclopedia groups the same ground into debug flags, object handles, exceptions, timing, process memory, assembly instructions, interactive checks and miscellaneous techniques, and is a useful catalogue for analysts. This guide stays at the defender's level and does not describe how to write the checks.

How adversaries use it: cases from ATT&CK v20

• Mustang Panda (G0129) and PlugX (S0013): ATT&CK records the group calling CheckRemoteDebuggerPresent and exiting if a debugger is found, citing Sophos, and embedding debug strings with messages meant to distract analysts, citing Trend Micro. See the Mustang Panda Threat Actor Profile Guide and the PlugX and ShadowPad Malware Guide.
• Lazarus Group in Operation Dream Job (C0022): tools used in the campaign called IsDebuggerPresent, citing ClearSky. See the Lazarus Group Threat Actor Profile.
• Lumma Stealer (S1213): checks foreground window text for debugger and disassembler names, citing Fortinet. See the Lumma Stealer Guide.
• Pikabot (S1145): Elastic Security Labs reported in February 2024 that the loader checks for a kernel debugger, a debug port, debug flags, the PEB BeingDebugged flag and hardware breakpoints, while the core repeats PEB and CheckRemoteDebuggerPresent checks throughout the binary, including before network requests. It also scans for tools such as Process Monitor, Wireshark and x64dbg and fingerprints window sizes to spot sandboxes.
• Ransomware: ATT&CK records LockBit 3.0 (S1202) checking heap memory for signs of a debugger and stopping events to an attached debugger, and the Black Basta (S1070) dropper checking flags, registers, instructions, timing, libraries and APIs. See the LockBit Threat Actor Profile and Black Basta Threat Actor Profile.
• Loaders and RATs: DarkGate (S1111) reads the PEB flag, Raspberry Robin (S1130) uses ThreadHideFromDebugger, AsyncRAT (S1087) and PureCrypter (S9019) call CheckRemoteDebuggerPresent, and XLoader (S1207) queries ProcessDebugPort. See the DarkGate Malware Guide, Raspberry Robin Malware Guide and AsyncRAT, Remcos and njRAT Commodity RATs Guide.

The pattern across these cases: debugger checks are bundled with sandbox checks (T1497), analysis-tool discovery and obfuscation (T1027). That bundling is what makes behavioural detection possible.

What to detect and where

ATT&CK v20 detection strategy DET0371 defines one analytic per platform.

Turning the analytic into something usable

Each signal above is common in benign software. Debuggable applications, crash handlers, game anti-cheat, licensing and DRM code, runtimes and security agents all ask whether they are being debugged, and many Linux programs read their own status file. NHI Mgmt Group recommends scoring rather than alerting on single events:

• Combine with process reputation: weight debug checks from unsigned, newly seen or user-writable-path binaries far above those from signed, prevalent software.
• Combine with discovery: enumeration of analysis tools by process name or window title (the Lumma and Pikabot pattern), or VM and sandbox checks (T1497), in the same process tree.
• Combine with execution anomalies: Elastic's Pikabot rules key on code running from unbacked memory and unusual remote memory writes; a debug check from such code is high signal.
• Watch for early exit: a new binary that performs environment checks and terminates within seconds without user interaction is worth a look, especially if it arrived by email or download.
• Use static triage: YARA rules for known families and for clusters of anti-debug imports and strings help prioritise samples, but imports alone are noisy. See the YARA Rules Guide.

Telemetry needed: Sysmon or EDR process events and API telemetry on Windows (see the Sysmon Guide), auditd rules on Linux scoped to suspicious paths to keep volume down (see the Linux Logging and auditd for Defenders Guide), and EDR or unified log collection on macOS.

Mitigations and analysis practice

ATT&CK lists no mitigations for T1622 and states that it cannot be easily mitigated with preventive controls because it abuses system features. The controls that matter therefore sit around it:

See the Malware Sandbox Guide and Malware Analysis Guide for Defenders for building those environments, and the AI-assisted reverse engineering for defenders guide for speeding up static work when dynamic analysis is evaded.

How to implement, in order

1. Confirm telemetry: check that EDR or Sysmon process events reach the SIEM from Windows endpoints, and decide where auditd collection on Linux servers is affordable.
2. Build a benign baseline: for two weeks, record which signed applications perform debug checks or read their own status file, and allowlist them by signer and path.
3. Deploy combination rules in hunt mode: debug checks plus analysis-tool discovery, sandbox checks, unbacked memory or early exit, scored by process reputation.
4. Tune and promote: review hits weekly, add allowlist entries with an owner and expiry, then promote stable rules to alerts.
5. Fix the analysis pipeline: add an "evasion observed" outcome to sandbox triage that routes the sample to a malware analyst.
6. Roll back cleanly: keep each rule independently disableable; if a rule floods after a software rollout, disable it, add the new application to the baseline and re-enable.

Decision guidance

• Small teams: rely on your EDR vendor's anti-analysis detections and on prevention. Spend effort on the triage rule: never close an incident on a clean sandbox verdict if the sample showed evasion.
• Mature SOCs and malware teams: write combination analytics, maintain hardened analysis environments, and track which families evade which environment.
• Linux and macOS fleets: start with servers that run untrusted code (build agents, shared hosts), where auditd and EDR coverage pay off most.

Where identity fits

Many of the families above are credential stealers. Lumma and Vidar steal browser sessions, tokens and saved secrets, which include API keys and cloud credentials used by automation. When a stealer evades analysis and runs, treat every credential on that machine, human and non-human, as exposed and rotate it. See the MITRE ATT&CK T1552 Unsecured Credentials Guide.

How to test your coverage

In a lab, run benign test programs written by your own team that call the documented debug-status APIs, read their trace status and enumerate process names, each alone and in combination, from signed and unsigned binaries. Confirm which events reach the SIEM, which rules fire and how the sandbox classifies them. Repeat after EDR or rule updates. Record results against T1622 using the ATT&CK coverage mapping guide.

Measuring it

• Percentage of Windows endpoints sending process telemetry with API or ETW coverage to the SIEM.
• False positive rate of combination rules per 1,000 endpoints per week.
• Percentage of sandbox verdicts marked "evasion observed" that received analyst review.
• Median time from evasive sample to family identification.
• Number of known evasive families with tested detection content.

Common failure patterns

• Alerting on IsDebuggerPresent imports alone: floods the SOC and gets the rule disabled.
• Trusting a clean detonation: the sample saw the analysis environment and stayed quiet, and the incident was closed.
• Analysis tools on production machines: debuggers installed on endpoints make the malware's tool checks a reason to hide there too, and widen the attack surface.
• No Linux or macOS telemetry: DET0371's Linux and macOS analytics cannot run without auditd or EDR data.
• Not rotating credentials after a stealer: evasion delays discovery, so tokens and keys may already be in use elsewhere.

Framework mapping

Practitioner checklist

• Confirm Windows process and API telemetry, Linux auditd coverage and macOS EDR coverage for in-scope systems.
• Baseline and allowlist signed software that performs debug checks.
• Detect combinations: debug checks with tool enumeration, sandbox checks, unbacked memory or early exit.
• Score by process reputation and path rather than alerting on single API calls.
• Add an "evasion observed" sandbox outcome that forces analyst review.
• Keep debuggers and analysis tools off production endpoints.
• Rotate all credentials on a host where an evasive stealer ran.
• Test detections with benign in-house test programs after each EDR or rule change.

Standards and references

• MITRE ATT&CK: T1622 Debugger Evasion
• MITRE ATT&CK: T1497 Virtualization/Sandbox Evasion
• Microsoft Learn: IsDebuggerPresent function
• Microsoft Learn: NtQueryInformationProcess function
• Linux man-pages: proc_pid_status(5)
• Check Point Research: Anti-Debug Tricks
• Elastic Security Labs: PIKABOT, I choose you!
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: MITRE ATT&CK T1497 Virtualization/Sandbox Evasion, Ghidra for Malware Analysis Guide, ATT&CK Stealth and Defense Impairment Tactics Guide, EDR Evasion and Defence Guide, ATT&CK Discovery Tactic (TA0007) Guide.