Obfuscated Files or Information: Software Packing

ID Name
T1406.001 Steganography
T1406.002 Software Packing

Adversaries may perform software packing to conceal their code. Software packing is a method of compressing or encrypting an executable. Packing an executable changes the file signature in an attempt to avoid signature-based detection. Most decompression techniques decompress the executable code in memory.

Utilities used to perform software packing are called packers. An example packer is FTT. A more comprehensive list of known packers is available, but adversaries may create their own packing techniques that do not leave the same artifacts as well-known packers to evade defenses.

ID: T1406.002
Sub-technique of:  T1406
Tactic Type: Post-Adversary Device Access
Tactic: Defense Evasion
Platforms: Android, iOS
Version: 1.1
Created: 30 March 2022
Last Modified: 12 May 2026

Procedure Examples

ID Name Description
S1094 BRATA

BRATA has utilized commercial software packers.[1]

S0432 Bread

Bread payloads have used several commercially available packers.[2]

S1225 CherryBlos

CherryBlos has used a commercial packer named Jiagubao to evade static detection.[3]

S9004 Crocodilus

Crocodilus dropper and payload have been packed to hinder detection.[4]

S0406 Gustuff

Gustuff code is both obfuscated and packed with an FTT packer.[5]

S1062 S.O.V.A.

S.O.V.A. has been distributed in obfuscated and packed form.[6]

Mitigations

This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.

Detection Strategy

ID Name Analytic ID Analytic Description
DET0644 Detection of Software Packing AN1721

From the defender view: a sandboxed process receives/creates a high-entropy Mach-O/bundle or encrypted segment, performs in-memory decrypt/unpack (mmap/mprotect RW→RX or RWX), optionally drops a transient image in app-writable dirs, then loads it through dyld/dlopen or spawns it. We correlate: (1) opaque blob write/arrival → (2) kernel memory protection changes → (3) dyld/dlopen from app-writable path or posix_spawn of a recently created image → (4) (optional) code-sign evaluation anomalies for the new image.

AN1722

From the defender view: a sandboxed app handles a high-entropy executable blob, performs rapid decode/decrypt in memory (often with RW→RX or execmem friction), optionally emits a transient .dex/.so into app-writable paths, then immediately loads/executes it (DexClassLoader/dlopen) or spawns a helper. We correlate: (1) opaque blob write/arrival → (2) decode/unpack or memory protection change → (3) new code artifact or byte[] class definition → (4) dynamic load/exec within a tight window.

References