- AN1045 · Analytic 1045 — Monitor for suspicious use of Windows API calls such as IsDebuggerPresent() and NtQueryInformationProcess(), or processes manually checking the BeingDebugged flag in the Process Environment Block (PEB). Detect sequences of OutputDebugStringW() calls in short intervals that may indicate debugger flooding attempts.
- AN1046 · Analytic 1046 — Monitor access to /proc/self/status where TracerPID field is queried, as this is a common technique for debugger detection. Detect processes that attempt to trigger exceptions intentionally and monitor whether exception handling indicates presence of a debugger.
- AN1047 · Analytic 1047 — Detect suspicious calls to sysctl or ptrace API used to determine if a process is being debugged. Monitor for processes that flood OutputDebugString equivalents or generate abnormal exceptions to evade analysis.
AdversaryGraph public intelligence page
This page is part of Threat Matrix, the public browser workspace for the main AdversaryGraph platform. Use it for ATT&CK pivots, actor and technique context, similarity leads, detection coverage review, and analyst-ready investigation paths.
Validation disclaimer: TTP overlap, actor similarity, generated summaries, and coverage findings are investigation leads, not attribution proof or operational validation without analyst review.
Main AdversaryGraph project Documentation Malware Analysis GitHub
Debugger Evasion
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.(Citation: ProcessHacker Github) 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](https://attack.mitre.org/techniques/T1497), 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](https://attack.mitre.org/techniques/T1106) function calls such as <code>IsDebuggerPresent()</code> and <code> NtQueryInformationProcess()</code>, or manually checking the <code>BeingDebugged</code> 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.(Citation: Cado Security P2PInfect 2023)(Citation: Positive Technologies Hellhounds 2023) 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).(Citation: hasherezade debug)(Citation:…
Open detection, hunting, mitigation, and evidence workspace
Detection logic
Debugger related system checks will likely occur in the first steps of an operation but may also occur throughout as an adversary learns the environment. Data and events should not be viewed in isolation, but as part of a chain of behavior that could lead to other activities, such as lateral movement, based on the information obtained. Detecting actions related to debugger identification may be difficult depending on the adversary's implementation and monitoring required. Monitoring for suspicious Native API function calls as well as processes being spawned that gather a variety of system information or perform other forms of Discovery, especially in a short period of time, may aid in detection. Monitor debugger logs for signs of abnormal and potentially malicious activity.
Observed actors
Correlated CTI and IR reports
Cyber Knowledge context
Use these routes to move from the ATT&CK behavior into explanation, implementation, evidence handling, validation, and defensive operations. Relevance is generated from explicit identifiers/names and governed topic mappings; it is not attribution evidence.
Malware Analysis & Reverse Engineering · Tactic learning route · 24/100Module 4 — Detection engineering and detection as code
Blue Team & Defensive Security · Tactic learning route · 24/100Disk, file-system, and persistence forensics
Digital Forensics & Incident Response (DFIR) · Tactic learning route · 24/100Internet exposure, service indexes, and infrastructure search
OSINT & Reconnaissance · Tactic learning route · 24/100Module 5 — Cloud, containers, and Kubernetes
Red Team & Offensive Security · Tactic learning route · 24/100Data classification, storage, cryptography, keys, backup, and deletion
Cloud Security · Tactic learning route · 24/100
MITRE mitigations
No ATT&CK mitigation relationship is published for this technique. Apply risk-based controls and verify scope.
MITRE detection strategies and analytics
Continue the investigation
Attack tools, simulations and detection rules
Follow explicit source relationships into the reference modules. Linked procedures and detectors are not claims of live validation or actor attribution.
- T1622 Debugger Evasion simulation — Exact active technique ID
- T1622 detection rules — Exact active technique ID; not actor-specific detector coverage