MITRE T1027 Detection: Sub-Technique Guide

Every SOC analyst knows T1027. It appears in threat reports, detection rules, and incident timelines constantly. MITRE's documentation tells you what it is and which groups use it. What it doesn't tell you is what to actually do when you encounter it. The mitigation section for T1027 reads: "Antivirus/Antimalware" and "Behaviour Prevention on Endpoint." That's not actionable. When an alert fires on T1027.010 (Command Obfuscation), the analyst needs to know: what kind of obfuscation am I looking at? What tools reverse it? How do I get from encoded blob to IOCs? This guide fills that gap. Each sub-technique gets a practical treatment: what it looks like, how to detect it, and how to reverse it.

The Gap Between Description and Defence

MITRE ATT&CK is the shared language of cyber defence. Threat intel reports reference technique IDs. Detection rules map to ATT&CK. Purple team exercises test against the matrix. But the framework was designed to document adversary behaviour, not prescribe defensive tooling. That's by design. MITRE is vendor-neutral.

The consequence is a gap. The analyst knows an alert is T1027. They know the sub-technique. They even know which threat group commonly uses it. What they often don't know is the practical next step. The framework points to the problem but not the solution.

For T1027 specifically, the gap matters because obfuscation is a wrapper around something valuable. The obfuscated content contains C2 URLs, payload instructions, and configuration data. If you can reverse the obfuscation, you get actionable IOCs. If you can't, you get a binary blob and a detection alert with no follow-through.

T1027.010: Command Obfuscation

This is the workhorse. The sub-technique covers any modification to command-line syntax that hides the command's true purpose. In practice, it's dominated by PowerShell, though it applies equally to cmd.exe, bash, and other interpreters.

The most common variant: PowerShell's -EncodedCommand flag, which accepts a Base64-encoded UTF-16LE script. The encoded string looks like random characters to any log parser that doesn't know to decode it. Other variants include tick insertion, case randomisation, environment variable slicing, and format-string assembly.

Detection signals: command-line arguments with entropy significantly above normal, the -e or -enc flag in PowerShell invocations, single-line commands exceeding typical length thresholds, and the presence of [Convert]::FromBase64String or IO.Compression in script blocks logged by AMSI.

Reversal: decode the Base64 payload (accounting for UTF-16LE encoding), normalise casing, remove tick characters, resolve format-string expressions. For multi-layer chains where the decoded output is itself obfuscated, iterate. This is where manual CyberChef recipes become impractical and automated deobfuscation becomes necessary. Language-specific reversal patterns: JavaScript string-array obfuscation covers obfuscator.io tier resolution (array, accessor, rotation, RC4), and Python exec() chains covers the recursion and compression-plus-Base64 layering typical of Python loaders.

T1027.013: Encrypted/Encoded File

The broad sub-technique covering any file or payload that is encrypted or encoded to evade detection. This includes Base64-encoded scripts delivered as email attachments, XOR-encrypted payloads embedded in documents, RC4-encrypted second stages carried by loaders, and compressed archives with encoded content.

In plain terms: if the malicious content doesn't look malicious because it's been scrambled, that's T1027.013. It's the catch-all for encoding, encryption, and compression applied to files or file contents.

Detection: file entropy analysis flags high-entropy files that should be readable text. Base64 content detection identifies the characteristic character set (A-Z, a-z, 0-9, +, /) and padding (=). Magic byte scanning finds compressed streams (GZIP's 1f 8b, LZMA's 5d 00) inside files that shouldn't contain them.

Reversal: this sub-technique covers the full obfuscation taxonomy. Encoding is reversed by format detection and algorithm application. Encryption requires key discovery, either through brute-force for single-byte XOR or key extraction for RC4/AES. Compression needs algorithm identification and decompression. Multi-layer samples require all three in sequence.

T1027.002: Software Packing

Packing compresses or encrypts a PE executable so its original code and data are hidden until runtime unpacking. Common packers include UPX (legitimate but widely abused), Themida, VMProtect, and custom packers written by malware authors.

Detection: section entropy analysis reveals packed executables because compressed or encrypted sections have entropy approaching 8.0 (the theoretical maximum for random data). Unusual section names (.UPX0, .themida), small import tables (packed binaries import only the unpacking APIs), and large size disparities between on-disk and in-memory footprint all signal packing.

Reversal: standard packers like UPX can be unpacked statically. Custom packers typically require dynamic analysis: running the sample in a controlled environment and dumping the unpacked code from memory. This sub-technique sits at the boundary between static and dynamic analysis capabilities.

T1027.006: HTML Smuggling

HTML smuggling constructs malicious files inside the browser using JavaScript. An email or web page delivers an HTML file containing a JavaScript payload that assembles a binary file from encoded data and triggers a download. The malicious content never crosses the network as a recognisable file, bypassing network-level inspection.

Detection: monitor HTML attachments for JavaScript containing Blob constructors, atob() calls, Uint8Array creation, URL.createObjectURL, and document.createElement('a') patterns. These are the building blocks of HTML smuggling. Network inspection tools should flag HTML files with embedded Base64 blobs exceeding typical sizes.

Reversal: extract the JavaScript from the HTML, identify the encoded data (usually Base64), decode it, and analyse the resulting file. The decoded file is often itself obfuscated, creating a multi-layer chain that starts with HTML smuggling and continues through script obfuscation.

T1027.003: Steganography

Payloads hidden in image files, audio files, documents, or other non-executable carriers. The carrier file is legitimate. It opens normally in an image viewer or document reader. The malicious content is invisible without specific extraction techniques.

Detection and reversal for steganographic sub-techniques are covered in depth in the dedicated articles: Steganography in Malware Delivery covers embedding techniques, Steganography Detection Techniques covers extraction and analysis, and Browser Extension Analysis covers steganographic icon hiding in the DarkSpectre campaigns.

T1027.009: Embedded Payloads

Malicious content embedded within otherwise legitimate files. Unlike steganography, which hides data imperceptibly, embedded payloads are appended or inserted in ways that don't affect the host file's functionality. Data appended after a JPEG's FF D9 end marker or a PNG's IEND chunk is ignored by image viewers but readable by the malware's extraction routine.

Detection: compare actual file size against expected size for the file type. Check for data after known end-of-file markers. Scan for magic bytes or encoding patterns (Base64 character sets, compression headers) in trailing data. Polyglot files that validate as multiple formats simultaneously are a strong indicator of embedded payloads.

T1140: The Runtime Mirror

T1140 (Deobfuscate/Decode Files or Information) is the other half of the equation. Where T1027 describes how the attacker obfuscates, T1140 describes what the malware does at runtime to reverse its own obfuscation. Every T1027 technique has a T1140 counterpart, because the malware must decode its own content to use it.

For defenders, T1140 represents an opportunity. If the malware can decode itself at runtime, a static analysis tool can decode it before runtime. The algorithms are the same. The only question is whether you apply them before or after execution.

Detection of T1140 in runtime telemetry: monitor for FromBase64String(), IO.Compression.DeflateStream, IO.MemoryStream in PowerShell script block logging. Watch for eval(), Function() constructors, and atob() in JavaScript contexts. These are the runtime deobfuscation functions that T1140 covers.

Building a T1027 Response Playbook

The practical application of this guide is a triage playbook. When a detection fires on T1027, the sub-technique tells you what category of obfuscation you're facing. The category tells you which reversal approach to apply. The reversal gives you IOCs.

T1027.010 alert? Check for -EncodedCommand, decode Base64, continue through any inner layers. T1027.013 alert? Identify the encoding or encryption type, apply the appropriate decoder, check if the output contains further obfuscation. T1027.006 alert? Extract JavaScript from HTML, decode the assembled binary, analyse the result.

The pattern is consistent: detect the sub-technique, reverse the obfuscation, extract the intelligence. The sub-technique identification is the detection team's job. The reversal can be automated. The intelligence extraction is where the defensive value lives.