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

DET0023: Obfuscated Binary Unpacking Detection via Behavioral Patterns

This detection strategy is about finding behavior consistent with packed or protected binaries being unpacked at runtime. The business value is reducing re...

EnterpriseDET0023Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This detection strategy is about finding behavior consistent with packed or protected binaries being unpacked at runtime. The business value is reducing reliance on file signatures alone: packed software can change how a file looks on disk while still revealing suspicious behavior in memory or execution flow. For leaders, the key question is whether the SOC can recognize stealthy execution patterns when static malware identification is weak or inconclusive.

Executive priority

Prioritize this as a resilience and detection-depth issue. The related ATT&CK technique, Software Packing (T1027.002), is associated with stealth across Linux, macOS, and Windows. Security leaders should ask whether endpoint and investigation telemetry can support behavioral detection and incident triage when executables are compressed, encrypted, or protected to evade signature-based controls. This is especially relevant for managed detection quality, IR readiness, and audit evidence showing layered defenses beyond hash or signature matching.

Technical view

The supplied ATT&CK object has no official description, detection text, platforms, or tactics of its own. Its value comes from the relationship stating that it detects T1027.002 Software Packing. SOC and detection engineering teams should validate behavioral coverage for executables that change from packed or protected form into executable code during runtime, especially where code is decompressed in memory. Use the related technique context to focus on stealth behavior rather than static file identity alone.

Likely telemetry

  • Endpoint process execution events
  • File creation and modification events for executables
  • Memory-related telemetry indicating code unpacking or execution from memory
  • Module or image load events
  • Endpoint security alerts related to packed, compressed, encrypted, or protected binaries

Detection direction

  • Validate that detections do not depend only on file hashes, filenames, or static signatures, since the related technique explicitly describes signature evasion through packing.
  • Tune behavioral analytics around runtime unpacking patterns, memory execution, and suspicious process behavior after an executable starts.
  • Correlate packed-binary indicators with subsequent process, file, module-load, and memory behaviors to reduce false positives from legitimate packed or protected commercial software.
  • Confirm coverage separately for environments where the related technique applies: Linux, macOS, and Windows, rather than assuming one endpoint control provides equivalent visibility everywhere.
  • Document blind spots where endpoint telemetry, memory visibility, or sandbox detonation is unavailable.

Mitigation priorities

  • Maintain layered controls that combine static analysis with behavioral endpoint monitoring.
  • Ensure SOC playbooks treat packed binaries as triage leads requiring behavioral context, not automatic proof of malicious activity.
  • Improve incident response readiness by preserving executable samples, process lineage, memory-relevant evidence, and related endpoint events.
  • Review allowlisting and exception processes for legitimate packed software so they do not create broad detection suppressions.
  • Use this coverage area as compliance evidence for layered malware detection and monitoring where local control data supports it.
Analyst notes and limits

This take is constrained by sparse ATT&CK fields: the detection strategy itself provides no official description or detection procedure. The only substantive context is the external reference to DET0023 and the relationship to T1027.002 Software Packing, whose description explains concealment through compression, encryption, or virtual machine software protection and notes that decompression often occurs in memory.

No active exploitation, attribution, effectiveness, specific data source, vendor control, or guaranteed detection coverage is stated in the supplied object. Local validation is required to determine whether telemetry exists, whether detections are enabled, and how much legitimate packed software exists in the environment.

Official MITRE ATT&CK definition

Obfuscated Binary Unpacking Detection via Behavioral Patterns

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 T1027.002 Software Packing Sub-technique This object detects Software Packing.
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
66366d4033b1ad10...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 66366d4033b1…
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 DET0023
    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.