Live Active security incident? Get immediate response
MITRE ATT&CK® Detection Strategy

DET0081: Detection of Proxy Execution via Trusted Signed Binaries Across Platforms

DET0081 matters because it focuses on adversaries using trusted signed system binaries as a proxy to run malicious content. For leaders, the issue is not j...

EnterpriseDET0081Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

DET0081 matters because it focuses on adversaries using trusted signed system binaries as a proxy to run malicious content. For leaders, the issue is not just malware execution; it is that normal, signed operating system tools may be abused in ways that can bypass simple allow-listing, signature trust, or process-name based monitoring. This makes coverage validation important across environments where the related ATT&CK technique, System Binary Proxy Execution, applies: Windows, macOS, and Linux.

Executive priority

Prioritize this as a control-validation and SOC-readiness issue. Ask whether the organization can distinguish legitimate administrative use of trusted binaries from suspicious proxy execution, and whether incident responders have enough endpoint telemetry to reconstruct parent-child process activity. This detection strategy supports resilience and audit conversations because it tests whether trust-based execution controls, endpoint monitoring, and investigation workflows can handle abuse of legitimate signed tools rather than only obvious malicious binaries.

Technical view

The supplied ATT&CK object is a detection strategy for T1218 System Binary Proxy Execution. Because the object has no official description, detection text, platforms, or tactics of its own, technical validation should be anchored to the relationship: adversaries may proxy malicious content through signed or otherwise trusted binaries, often to bypass process or signature-based defenses. SOC and detection teams should validate endpoint visibility into trusted binary execution, parent and child process relationships, command-line arguments, file/module/script content references where collected, and deviations from expected administrative baselines across Windows, macOS, and Linux environments where T1218 is relevant.

Likely telemetry

  • Endpoint process creation events, including executable path, signer/trust metadata where available, command line, parent process, and user context
  • Process ancestry and child process relationships for trusted system binaries
  • File access or execution evidence for content launched by trusted binaries
  • Endpoint security alerts or allow-list decisions involving signed or native operating system binaries
  • Authentication and user/session context tied to binary execution

Detection direction

  • Validate that detections do not rely only on unsigned or unknown binaries; the related technique explicitly involves signed or trusted binaries.
  • Baseline legitimate administrative and operating system use of trusted binaries before tuning, because false positives can come from normal system management activity.
  • Hunt for unusual parent-child process chains, unexpected command-line patterns, execution from uncommon directories, or trusted binaries launching content inconsistent with local norms.
  • Confirm coverage across Windows, macOS, and Linux only where those platforms are in scope and telemetry exists; the detection strategy object itself does not list platforms.
  • Use the relationship to T1218 to map this strategy to ATT&CK coverage for stealth-oriented behavior, while documenting gaps caused by missing command-line, parent process, or signer metadata.

Mitigation priorities

  • Start with visibility: ensure endpoint telemetry captures process creation, command line, parent process, user context, and trust/signature metadata where available.
  • Review allow-listing and application control policies so that trust in a signed binary is not treated as sufficient proof of benign behavior.
  • Limit unnecessary administrative access and reduce opportunities for users or processes to invoke powerful native binaries outside expected workflows.
  • Create incident response playbooks for suspicious trusted-binary execution, including rapid triage of process ancestry and launched content.
  • Use detection engineering reviews to test whether controls identify suspicious behavior around trusted binaries rather than only known malicious files.
Analyst notes and limits

This take is based on the DET0081 detection strategy object and its relationship to ATT&CK technique T1218, System Binary Proxy Execution. The source object does not provide official description or detection logic, so recommendations are framed as validation priorities rather than asserted detection rules.

The detection strategy object has sparse official fields: no official description, no official detection text, no tactics, and no platforms. Platform and tactic context comes only from the related T1218 technique summary provided. Local telemetry, administrative baselines, and control architecture are required to determine actual coverage or risk.

Official MITRE ATT&CK definition

Detection of Proxy Execution via Trusted Signed Binaries Across Platforms

No official description is available in the imported ATT&CK source object.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

ATT&CK relationship table

Techniques used

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1218 System Binary Proxy Execution This object detects System Binary Proxy Execution.
Relationship explorer

All related ATT&CK context

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
3c99c885ff554b77...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 3c99c885ff55…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack DET0081
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.