If a security tool can read a file, it can judge it. So attackers work to make files unreadable: compressed, encrypted, encoded, split up or otherwise disguised. That single idea covers a huge range of behavior, and it is among the most common things defenders run into.
MITRE tracks it as Obfuscated Files or Information, technique T1027, in the Stealth tactic. It spans ESXi, Linux, macOS, Network Devices and Windows. It has a long list of sub-techniques, and this post covers the parent idea. Other posts in this series take the individual variants one by one.
How attackers use it
MITRE describes the goal as making an executable or file difficult to discover or analyze by encrypting, encoding or otherwise obfuscating its contents, either on the system or in transit. A few patterns it lists:
- Compressed, archived or encrypted payloads. Used during initial access or later to avoid detection. A user may even have to type a password to open a protected archive that the adversary supplied. Compressed or archived scripts, such as JavaScript, also appear.
- Encoded strings. Parts of a file can be encoded to hide the plain text strings that would otherwise help defenders find it.
- Split payloads. A payload may be broken into separate, harmless looking files that only reveal their purpose when reassembled.
- Command obfuscation. Environment variables, aliases, characters and language specific syntax can be used to defeat signature based detection and application control.
Sometimes a user must act to decode the content, for example by opening a file and entering a password. That ties the technique closely to phishing and user execution.
How to detect it
MITRE's strategy (DET0378) gives analytics for each platform family:
- Windows. Script execution or suspicious parent processes that line up with the creation or change of encoded, compressed or encrypted files such as .zip, .7z or .enc, together with strange command line syntax or PowerShell obfuscation.
- Linux. Use of gzip, base64, tar or openssl in scripts or commands that encode or encrypt files after file staging or system enumeration.
- macOS. Archive or encryption tools such as zip and openssl tied to user scripted activity, or binaries writing encoded payloads under /Users or /Volumes.
- Network. Transfer of base64, uuencoded or high entropy files over HTTP, FTP or custom protocols during lateral movement or exfiltration.
- ESXi. Base64 encoded PowerCLI or payloads staged through datastore uploads or shell access.
There is a theme. You cannot reliably judge the obfuscated file, so you judge what is around it: the process that wrote it, the command that decoded it, the entropy of what crossed the wire and what ran next.
Useful logging to have in place:
- Command line capture. On Windows, process creation events (4688) with command line auditing, or Sysmon event ID 1.
- PowerShell script block logging (event ID 4104), which records the script after decoding in many cases.
- AMSI, the Antimalware Scan Interface, which lets security products inspect content after it has been interpreted.
- On Linux, auditd execve records for gzip, base64, openssl and similar tools run from unusual parents.
How to reduce the risk
MITRE lists four mitigations.
- Audit fileless storage locations. Review places such as the Registry and the WMI repository from time to time for abnormal data.
- Turn on Attack Surface Reduction (ASR) rules on Windows 10 and later to prevent execution of potentially obfuscated payloads.
- Use antivirus and AMSI. Anti-virus can detect and quarantine suspicious files. AMSI on Windows 10 and later lets tools analyze commands after they have been processed.
- Control ingress points to software deployment. MITRE lists this under user training: keep a finite number of ingress points to your deployment systems, with restricted access.
None of these looks at the payload as one big puzzle. They shrink the number of places where a decoded payload can run.
Check your own environment
# Windows: which ASR rules are configured and in what mode?
Get-MpPreference | Select-Object AttackSurfaceReductionRules_Ids, AttackSurfaceReductionRules_Actions
# Windows: is command line capture on for process creation events?
auditpol /get /subcategory:"Process Creation"
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled
# Windows: is PowerShell script block logging configured?
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging"
# Linux: are auditd rules loaded?
sudo auditctl -l
Then review:
- Do you log full command lines on Windows, Linux and macOS endpoints?
- Do your mail and web gateways open archives, and what happens with password protected ones?
- Are ASR rules in block mode, or only in audit mode?
- Do you have a regular review of the Registry and WMI repository for unusual stored data?
Quick check
Why does MITRE tell defenders to look at behavior around obfuscated files?
Because obfuscation is meant to defeat inspection of the file itself. The process that created it, the command that decoded it, the entropy of the traffic and the execution that follows are still visible.
What do ASR rules and AMSI each add on Windows 10 and later?
ASR rules help prevent execution of potentially obfuscated payloads. AMSI lets security tools analyze commands after they have been processed or interpreted.
Name two forms of obfuscation named in the technique description.
Compressed, archived or encrypted payloads, encoded strings, payloads split into separate files, or obfuscated commands. Any two of these.
Sources
- MITRE ATT&CK, Obfuscated Files or Information (T1027)
