How T1622 debugger evasion hides malicious activity from analysts
An alert fires on a suspicious process, the analyst opens it in a debugger or sandbox, and the process suddenly does nothing interesting. No network calls, no file drops, no obvious child processes. The SOC lead then has to decide whether the sample is benign or whether the malware noticed the analysis and went quiet. T1622 Debugger evasion, a technique under the Stealth tactic (TA0005), describes exactly this pattern: the adversary checks whether a debugger is attached and changes its behavior so that analysis reveals less than the real intent. Per the ATT&CK definition of the tactic, the goal is to hide actions and appear as normal behavior. In intrusions, this check tends to appear in loaders, droppers and staged payloads that are examined by analysts or automated detonation systems, so it matters most during incident triage and malware analysis.
This page targets MITRE ATT&CK Enterprise version 20.0. Technique IDs, names and mappings can change between ATT&CK releases, and releases can rename, deprecate or revoke techniques, so confirm T1622 and its detection strategy against the version your detection content references before you rely on it. The ATT&CK technique page and the MITRE ATT&CK tactic page for Stealth are the natural starting points for that check. Also confirm whether your analysis tooling and sandboxes are in scope for the telemetry you collect, because the behavior is only visible if process and API activity from the analysis environment reaches your monitoring pipeline.
The practical decision for the SOC lead is whether a process that behaves differently under analysis should be treated as suspicious in its own right. Teams that treat the absence of activity as proof of benignity are exposed here. A reasonable position is to record the analysis conditions, compare behavior across at least two environments, and escalate when a process changes behavior after a debugger or analysis tool appears in its telemetry. Confirm with your analysis team which environments, tools and logging are available, and who approves a judgment that a sample is evasive rather than broken.
Which telemetry reveals debugger evasion on each platform
This table maps the telemetry that exposes T1622 Debugger Evasion on Linux, macOS and Windows to the open-source collector that gathers it. Read each row as a starting point for a detection, then confirm the data component mapping against the ATT&CK v20 detection strategy before you deploy rules. The main takeaway is that process creation context is the common thread, and OS API and file access telemetry add the evidence that confirms intent.
| Platform or layer | Telemetry to collect | Open-source collector | Signal analysts should look for |
|---|---|---|---|
| Linux | Process creation (DC0032) and auditd syscall records for process tracing calls | auditd, with Wazuh agent forwarding; Velociraptor for hunts | Processes querying or altering their own debug state, followed by changed execution behavior |
| macOS | Process creation and Endpoint Security framework events for process inspection | Wazuh agent or Velociraptor client; confirm which Endpoint Security event types your macOS version exposes | Unexpected inspection of a process's debugging status before sensitive activity begins |
| Windows | Process creation, OS API execution and file access on binaries and scripts | Sysmon-style logging forwarded by Wazuh agents; Velociraptor for targeted collection | Calls to debugger-status APIs from processes with no legitimate debugging role |
| Cross-platform correlation | Process creation paired with file access to the samples or scripts that ran | Wazuh rules for correlation; Velociraptor artifacts for file collection | A debug-check event followed by a process exiting or skipping its payload path |
| Verification step | Mapping of T1622 to data components in the ATT&CK v20 detection strategy | Enterprise ATT&CK v20 STIX bundle and the detection strategy page for T1622 | Confirm the listed data components and fields before you treat any mapping in this table as final |
Detection ideas for T1622 that SOC teams can tune
Debugger evasion checks are noisy on their own, because developers, IDEs, crash reporters and security agents all inspect processes for legitimate reasons. The cards below pair process context with debugger-related API and file activity, then tune the result against known legitimate attachers before alerting. Every rule should name the ATT&CK version it targets.
Correlate process creation with follow-on checks
Start from process creation events and look for a short chain in which a newly started process performs debugger-related OS API calls or reads process state files shortly afterward. A single call proves little, so the signal is the sequence, the parent process, and whether the binary runs from a user-writable or temporary path. Confirm the field names your Sysmon, auditd or EDR telemetry provides before writing the correlation, since ATT&CK data components such as Process Creation (DC0032) and OS API Execution describe the telemetry class, not a fixed schema. Alert on the chain, not the call.
Baseline legitimate debugging by developers
Build a baseline of which hosts, user accounts and parent processes normally attach debuggers or run profilers. Developer workstations, test runners and CI build agents will generate most of the hits, so separate them by host group and role. Ask engineering leads which toolchains are approved and which build images are in use, then record those as expected behavior. Review the baseline on a fixed schedule, because new language runtimes and debugger versions change what looks normal.
Set thresholds for repeated checks
Some malware checks for a debugger several times in a short window, before and after sensitive operations. Define a count of distinct debugger-related checks per process within a fixed time window, and alert only when that count exceeds the baseline for the host group. Thresholds should be set from your own telemetry during tuning, not copied from another environment. Test the threshold in the cyber range with benign programs that perform similar checks, so you can measure the false positive rate before production use.
Tune for IDEs, crash reporters and security tools
Debuggers are not the only processes that attach to others. IDEs, crash reporters, endpoint agents, backup software and performance monitors all read or attach to process state for legitimate reasons. Build an allowlist keyed on signed binary identity, install path and parent process, not on process name alone, since names are easy to copy. Review each allowlist entry with the owning team and set an expiry so stale exceptions do not hide future activity.
Document false positive sources explicitly
Record each known false positive source in the detection's documentation: the software, the host group, the reason it triggers, and the owner who approved the exception. Include build systems, test harnesses, reverse engineering labs and vendor support tools. This record lets an analyst decide quickly whether an alert matches a known source, and it gives auditors evidence that exceptions were reviewed. Revisit the list after each software change on engineering endpoints.
Write Sigma rules against the target ATT&CK version
Sigma rules for T1622 should state the ATT&CK version they target, because MITRE releases can rename, deprecate or revoke techniques and change detection mappings. Version 20.0 of Enterprise ATT&CK is the reference for these pages. When ATT&CK changes, re-check the technique mapping, the data component references and any tags in each rule before deploying the update. Store the target version in the rule metadata so that future reviewers can tell which mapping an alert relied on.
How to validate that the T1622 detection fires
This sequence proves, in a private cyber range, that the T1622 Debugger Evasion detections fire on the expected telemetry, within an acceptable alert path, and that every gap is recorded and assigned for closure. The output is an evidence pack the detection owner and the range owner can both sign off on.
Agree emulation scope with the range owner
The detection owner and the cyber range owner agree in writing which Linux, macOS and Windows hosts are in scope, which telemetry sources must be present (Process Creation, OS API Execution and File Access), and which ATT&CK version the detections target. Name the ATT&CK version explicitly, because the technique mapping can change between releases. Done means a signed scope note exists and both parties have confirmed the approved test window and the rollback procedure.
Prepare an isolated lab with a benign test workload
The range team builds an isolated lab with the in-scope endpoints, the Wazuh or Security Onion collectors, and a benign, approved test workload that produces the behavior the detection is meant to recognize. The workload is reviewed by the security team so it is safe, reversible and clearly labeled as test activity. Done means the lab is isolated from production networks, the collectors show healthy ingestion, and the test workload is recorded in the scope note with its owner.
Record expected telemetry before each run
Before any run, the detection owner writes down the expected telemetry for each host and each data component mapped to T1622, such as the process, API and file events that should appear and the fields they should carry. This baseline turns the exercise into a test with a pass or fail result rather than a judgment after the fact. Done means each test case has a documented expected-event table approved by the range owner.
Capture observed telemetry and alerts
The lab runs the approved test workload while the team captures raw events from the endpoint agents and the collectors, then compares them with the expected table. Record which events arrived, which fields were populated, and whether any expected event was missing or truncated. Done means a timestamped capture exists for each test case alongside the rule or analytic that should have fired.
Check alert fidelity and latency in the SIEM
In Wazuh or Security Onion, the analyst checks whether the alert fired, whether it fired on the right host and user context, and whether it carried enough detail to triage without re-querying. Measure the time between the test action and the alert appearing in the console. Fidelity issues such as false positives from benign debugger use on developer hosts are also logged. Done means each test case has a recorded result for alert presence, accuracy, and latency, and the latency figures are compared with the target the detection owner agreed in advance.
Document gaps and assign remediation
Each test case that did not produce the expected telemetry or alert is logged as a gap, with the cause identified where possible, such as a missing logging policy, a collector configuration issue, or a rule threshold. The owner and target date for each fix are recorded in the tracker. Mitigations such as Audit (M1047) and Behavior Prevention on Endpoint (M1040) are considered where they apply. Done means every gap has an owner, a fix plan, and a retest scheduled in the same range.
Retest and sign off the evidence pack
After fixes are applied, the team reruns the affected test cases in the same isolated lab and confirms the expected telemetry and alert now appear. The final evidence pack contains the scope note, expected tables, captures, alert records, latency results, gap log and retest outcomes. Both the detection owner and the range owner sign the pack, and it is stored for later comparison when the ATT&CK version or the logging configuration changes. Done means a signed evidence pack exists for the ATT&CK version under test.
Preventive controls that reduce T1622 exposure
Four ATT&CK mitigations map to the Stealth techniques that T1622 Debugger evasion belongs with, so they are the controls to review first. Each one narrows a different step: what gets recorded, what gets blocked at runtime, which code is allowed to run, and who can change the files that matter. Confirm the T1622 mapping on the ATT&CK page for the version you target before you cite it in a control register.
Audit (M1047)
The Audit mitigation means the operating system and security tooling record the events that show a program checking for or attaching to a debugger. Confirm that process creation and OS API execution events are enabled and forwarded on the hosts where analysis tools or sensitive workloads run. Check the retention period against your investigation needs, and confirm that audit policy changes are themselves logged. Without these records, the Stealth detections described on this page have nothing to match against.
Behavior Prevention on Endpoint (M1040)
Behavior Prevention on Endpoint relies on endpoint protection that judges what a process does at runtime, not only what its file looks like. For T1622, the relevant behaviors include a process probing its own debugging state or attaching to another process in ways that suggest it is hiding from analysis. Check that these behavior rules are enabled and tested against your developer and reverse engineering workstations, where legitimate debugging is common. Record each exception with an owner and a review date.
Execution Prevention (M1038)
Execution Prevention limits which binaries, scripts and libraries are permitted to run on a host. Application control with an allowlist reduces the chance that an unapproved program can perform debugger checks and then change its behavior. Start enforcement in audit mode on build servers and analyst workstations, review what would have been blocked, and then move to enforcement. Confirm how the policy handles signed developer tools, since these are the most likely source of false positives and exceptions.
Restrict file and directory permissions (M1022)
Restricting file and directory permissions reduces who can alter the binaries, configuration files and tool directories that a Stealth technique would need to change. If an attacker can replace a debugging helper or edit a monitoring agent's configuration, detection coverage can quietly shrink. Review write access on tooling and security agent paths and remove broad group rights. Check ownership on these paths after each software update, because updates often reset permissions to defaults.
How to triage and respond when a T1622 alert fires
Start by confirming what the alert actually observed. For T1622 Debugger evasion, the triage question is whether a process checked for an attached debugger or altered its own debugging state, and by which parent it was launched. Pull the process lineage first: the parent chain, the command path, the signing details and the working directory. Then establish account context: which user or service identity owned the session, whether that identity normally runs developer tooling on this host, and whether the logon was interactive, scheduled or remote. A debugger check made by a browser or a known application on a workstation the user normally uses is a very different event from the same check made by an unsigned binary in a temporary directory under a service account.
Next, decide whether the binary is a known developer or security tool. Compare the file hash, signer and install path against your asset inventory and your approved software list. Engineering teams often run profilers, reverse engineering tools and debuggers, and endpoint or forensic agents also inspect processes, so a match is not automatically benign. Ask the owning team to confirm the tool and the change ticket, and record the answer. If the binary cannot be attributed, treat it as unknown. Before you touch the host, preserve volatile evidence with Velociraptor: capture running process details, loaded modules, network connections and the relevant file artifacts, and keep a hash record of what you collected. Confirm the collection scope and retention rules with your incident response lead, since the exact Velociraptor artifacts available depend on your deployment version.
Rehearsing T1622 detection in a private cyber range
On Linux lab hosts, the range should include a monitored endpoint with the Wazuh agent deployed and audit-style process telemetry enabled, placed on a segment where Security Onion or Zeek sees the surrounding network traffic. Suricata can run on the same segment to correlate any outbound callbacks the exercise produces. The range coordinator controls the injects: a scripted process that checks for an attached debugger through the operating system interface, and a second scripted process that exits early when that check succeeds. Good detection means the process creation events are indexed with parent, command line and user context, and that analysts can connect the debugger-check activity to the process that performed it within the agreed triage window. Good response means the analyst documents the host, preserves the process tree, decides whether the behavior is benign tooling or hostile, and records the decision in the exercise log. Confirm with your Wazuh and Security Onion versions which decoders and rule sets ship for your audit configuration.
- Telemetry baseline: Confirm that process creation records include the parent process and full command line before the exercise starts.
- Injected behavior: The coordinator scripts a debugger-check inject and a benign developer tool inject so analysts must separate the two.
- Correlation path: Check that Wazuh alerts can be pivoted to Security Onion case records for the same host.
- Network context: Zeek logs should show whether any inject produced outbound connections that Suricata alerts on.
- Response checkpoints: Score containment time, evidence preservation and the quality of the written triage note.
Before the exercise, ask the provider to confirm in writing which telemetry sources, host images and time windows are in scope.
On macOS lab hosts, the range should include an endpoint with a supported endpoint agent or log collector forwarding unified logging and process events to the SIEM, with Wazuh used where its macOS coverage meets your requirements. Network visibility comes from Zeek and Suricata on a mirrored segment, which helps when an inject attempts to reach an external destination. The coordinator controls injects such as a signed developer tool that queries process state, and an unsigned script that performs a similar check and then terminates. Good detection means analysts can tell signed Apple and developer binaries from unsigned or unexpected ones, and that process lineage survives in the stored events. Good response means the analyst isolates the host according to the runbook, collects the process and log evidence, and notes whether the tooling was approved for that user. Because macOS log retention and agent coverage vary by version, ask the provider to confirm both before you finalize the scenario.
- Agent coverage: Verify which macOS process and file events the chosen agent records on your target versions.
- Signing context: Include signed and unsigned inject binaries so analysts practice checking code signature state.
- Lineage checks: Confirm that parent and child process relationships are retained in the SIEM index.
- Network evidence: Use Zeek connection logs and Suricata alerts to confirm or rule out callbacks.
- Containment drill: Practice isolation and evidence collection on a non-production host image.
Ask the provider to document the exact macOS versions and agent builds used in the range.
On Windows lab hosts, the range should include Sysmon-style or equivalent process, image load and process access telemetry forwarded to Wazuh, with Security Onion providing the wider network and alert view. Zeek and Suricata sit on the segment to capture any network activity from injects. The coordinator controls injects that call operating system debugger-detection functions from a test binary, a legitimate debugger attached to a benign sample, and a process that inspects another process for debugging state. Good detection means analysts see the relevant process creation and process access events, can distinguish a developer debugging its own build from an unexpected process inspecting a sensitive process, and map the activity to the ATT&CK technique using the detection strategy for the version you target. Good response means the analyst preserves the event evidence, confirms the process and user context, and escalates according to the runbook. Confirm the Windows build and event configuration with your provider before the exercise, since audit policy changes what is recorded.
- Event configuration: Confirm which Windows audit and Sysmon-style event types are enabled on each lab image.
- Benign and hostile injects: Mix a developer debugging session with a suspicious inspection to test analyst judgment.
- ATT&CK mapping: Ask analysts to record the detection strategy and data components they relied on, using ATT&CK v20.0 as the reference.
- Network and alert view: Check that Security Onion shows the same host activity that Wazuh records.
- Escalation drill: Test the handoff from the analyst to the incident lead and record the timing.
Confirm in writing the exercise scope, the time window and the injects the coordinator will run before any lab host is started.
Questions detection engineers ask about T1622
How do I separate developer debugging from debugger evasion on my endpoints?
Treat a debugger attach as an event that needs context before it becomes an alert. A single attach is weak evidence on its own, so score it against the parent process, the user account, the host role and the time window. Developer workstations and build agents should have their own expected baseline, while production servers, kiosks and hosts in regulated zones should rarely or never show debugger activity. Build allowlists per host group rather than per individual user, and review them with the engineering teams that own those hosts. Confirm the exact telemetry each platform provides for T1622 in your environment before writing logic, then replay recorded developer sessions in a cyber range to see where false positives appear.
Which MITRE ATT&CK version should our detections target?
Target ATT&CK version 20.0 and record that version in the metadata of every detection. The version matters because v18 replaced technique-level detections with detection strategies and analytics, updated data components and deprecated some data sources. In v19, the Enterprise Defense Evasion tactic was split, with Stealth keeping ID TA0005 and the new Defense Impairment tactic receiving TA0112. Check the T1622 entry and its data component references in the STIX bundle for the version you adopt, because a detection written against an older mapping may point at the wrong tactic. Ask your SIEM or detection platform vendor which ATT&CK version their bundled content uses.
How should we handle ATT&CK technique ID changes over time?
Keep a crosswalk that links each detection rule to its ATT&CK technique ID, tactic, data components and the version it was tested against. When MITRE publishes a new release, review the update notes and the STIX bundle for changes to T1622, including renames, deprecations and revocations. Revoked or deprecated objects should trigger a review rather than a silent edit, and each change should be logged with the date, the reviewer and the test result. Store rules as code so changes can be diffed and traced. MITRE publishes release details on its updates pages, which is the natural next read for planning this review.
Does network telemetry add value for detecting debugger evasion?
Network telemetry can add context, but it is usually a supporting signal rather than the primary one for T1622. Host telemetry such as process creation, OS API execution and file access carries most of the detection logic. Network connection records can help when a debugging session is tied to a listener or a remote management channel that the team did not expect, and they can help correlate host events across machines. Whether a given data component supports T1622 depends on the ATT&CK version and your sensor placement, so confirm the mapping in the detection strategy for your target version. Test any network rule in the range before relying on it in production.
How do we measure detection quality for T1622 in a cyber range?
Measure detection quality with a written test plan that covers each platform in scope, including Linux, macOS and Windows. Define benign test cases, such as developer debugging on a workstation, and adversary-style test cases that emulate debugger evasion, then record whether each one produced an alert, how long the alert took to appear, and which fields the analyst needed. Track false positives per host group, because a rule that is quiet on a lab server may be noisy on build agents. Compare results across ATT&CK versions and sensor changes, and keep the results as evidence. Ask any provider to show their test plan and result format before the engagement begins.
How often should we retest the T1622 detection?
Set the retest schedule in writing with the detection owner, and add event-driven retests on top of it. Retest after any change to a detection rule, after a new ATT&CK release that affects the T1622 mapping, after a change to logging agents or sensor configuration, and after an upgrade to the endpoint or SIEM platform. A recurring cadence also keeps coverage honest as developer tooling and host images change. The right interval depends on how often your environment changes and on the risk tolerance of the owners, so agree it with your security and engineering leads instead of adopting a default. Retesting in a private cyber range keeps production hosts out of the test path.
Can our own team run these detections, or do we need outside help?
Your team can run the detections if it has the skills in endpoint telemetry, SIEM content and incident response, and DeployOpen can support either path. Most engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts. DeployOpen can implement the telemetry pipeline, build the detection content, rehearse it in a private cyber range and document the evidence, while your team keeps ownership of the rules. Ongoing support, upgrades and continuous testing are available as retainers. To compare options, ask each provider which platforms they have covered, how they handle ATT&CK version changes and what documentation you will own at the end.
Primary sources for T1622 and ATT&CK Stealth
Start with the official ATT&CK tactic page for Stealth, which holds the tactic's definition and the list of techniques that fall under it. For T1622 Debugger evasion, use it to confirm that the technique still sits under Stealth in the version you deploy, since ATT&CK v19 split the former Defense Evasion tactic into Stealth (ID TA0005) and the new Defense Impairment tactic (TA0112). Read the MITRE ATT&CK tactic TA0005 page first, then open the technique page itself to review its sub-techniques and the data components it references.
Next, review the MITRE ATT&CK updates page, which lists each release with its changes. The release notes matter for this technique because they record when detection content moved to detection strategies and analytics, when data components were revised and when data sources were deprecated. Confirm which release your detection content targets, and record that version in every Sigma rule, Wazuh decoder or Security Onion query you write, so that a later rename or deprecation does not leave a silent gap in coverage.
For the machine-readable record, use the enterprise-attack 20.0 STIX bundle in the mitre-attack/attack-stix-data repository. It contains the technique relationships, detection strategy references and mitigation mappings in STIX 2.1 form, which makes it suitable for tooling that cross-checks your rules against the current catalog. Before you deploy, compare the detection strategy for T1622 in that bundle with the version your engineers implemented, and confirm with your platform team that the data components named there (such as Process Creation and OS API Execution) are actually collected in your environment.
How DeployOpen builds T1622 detections and range exercises
DeployOpen approaches T1622 Debugger evasion as a defined engagement: the detection logic, telemetry and response steps are agreed in writing before any work starts. Every detection is built on the client's own self-hosted open-source stack and rehearsed in a private cyber range before it is handed over.
How we scope
- Confirm which operating systems in your estate (Linux, macOS, Windows) are in scope for T1622 telemetry review.
- Agree which data sources feed the detection, such as process creation, OS API execution and file access logs.
- Record the ATT&CK version targeted, since releases can rename or revise technique mappings over time.
How we build
- Write detection logic for T1622 in plain-language analytics, then express it as open-source rules such as Sigma.
- Map collection points in Wazuh, Velociraptor or similar agents to the telemetry the rules depend on.
- Test false positive rates against your baseline of legitimate debugger and developer tool activity before tuning.
How we hand over
- Deliver rule files, configuration, and a runbook describing triage and escalation steps for T1622 alerts.
- Document the cyber range exercise results, including which injected test cases were detected and which gaps remain.
- Provide an agreed list of open items and owners so your team can continue tuning after the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover re-running range exercises when ATT&CK mappings or your endpoint agents change.
- Ask for the support scope, response expectations and change process in writing as part of your quote.
