T1027
Obfuscated Files or Information
A mainstay in our annual top 10, Obfuscated Files or Information remained a necessary component of most successful attacks in 2023.
Pairs with this song#5
overall rank
10.4%
customers affected
342
threats detected
Threat sounds
Mmm whatcha say? Adversaries hide malicious code from signature-based detection tools with Base64 encoding, string concatenation, and other forms of obfuscation.
Analysis
Why do adversaries obfuscate files or information?
Note: T1027 comprises multiple sub-techniques, but we largely map our detection analytics to the parent. As such, this section focuses generally on the overall technique and not on any individual sub-techniques.
Adversaries employ obfuscation to evade simple, signature-based detection analytics and to impede analysis. Since software and IT administrators also obfuscate files and information in the regular course of business, evasive obfuscation blends in with benign obfuscation. Ironically, some obfuscation techniques are so focused on fooling machines that they disproportionately draw human attention.
If you consider the conspicuousness of the alternative—performing clearly malicious actions in plain sight—it makes sense that adversaries would take the time and effort to encrypt, encode, or otherwise obfuscate files or information that, in plaintext form, would be obviously malicious and trivial to detect or block.
How do adversaries obfuscate files or information?
Many Red Canary threat detections are mapped to more than one ATT&CK technique, and we routinely analyze commonly co-occurring techniques to better understand adversary tradecraft. No two techniques co-occur more frequently than Obfuscated Files or Information and PowerShell (T1059.001). While the next duo’s not quite as dynamic, adversaries also regularly leverage obfuscation in conjunction with the Windows Command Shell (T1059.003). Obfuscation also pairs prolifically with Ingress Tool Transfer (T1105).
Of all the techniques that co-occur repeatedly in our data set, these three pairings tell perhaps the most obvious story: we constantly detect adversaries executing obfuscated commands in PowerShell and Windows Command Shell, occasionally for the purpose of clandestinely transferring tools.
Obfuscation comes in many forms, and the following section will attempt to describe those forms of obfuscation that are prevalent across the environments we monitor. Some types of obfuscation that stand out include:
- Base64 encoding
- string concatenation
- substrings
- escape characters
Base64 encoding
Base64 is the most common form of obfuscation across our detection data. Administrators and developers use Base64 encoding to pass scripts to subprocesses or remote systems and to conceal sensitive information (think: passwords). Yet again, the normality and utility of Base64 makes it an attractive tool for adversaries. If you’ve read the PowerShell section of this report, then it won’t shock you that most confirmed threats that employ obfuscation also use encoded PowerShell commands.
String concatenation
String concatenation is another common form of obfuscation that we observe. Adversaries use string concatenation for the same reasons they use Base64 encoding: to hide malicious strings from automated, signature-based detective and preventive controls. Some common forms of string concatenation include:
- the
+
operator combining string values - the
-join
operator combining characters, strings, bytes, and other elements - Since PowerShell has access to .NET methods, it can use the
[System.String]::Join()
method to combine characters, which is functionally equivalent to PowerShell’s native-join
operator - String interpolation enables another form of evasion by allowing adversaries to set values such that
u\
can equalutil.exe
, thereby allowingcert%u%
to executecertutil.exe
Substrings
Adversary use of substrings is probably the next most common form of obfuscation that we encounter. We’ll use the following as an example to explain how an adversary might leverage a substring:
$ENV:pubLic[13]+$env:PublIc[5]+’x’.
The plus signs here are string concatenation, which we’ve addressed. Looking on either side of the plus sign, we see a substring that will cause PowerShell to combine the 14th and sixth characters (note: the first element of an array starts at 0) from the public environment variable. On most systems, the public environmental variable will be C:\Users\Public
. You can do the counting, but the resulting substring is ie
. The +
operator then adds an x
on the end, resulting in the shortened version of the Invoke-Expression
cmdlet, which will execute the code passed to it. The use of a substring like this offers adversaries a reliable way to subvert detection analytics that look for PowerShell execution in conjunction with iex
or Invoke-Expression
in the command line.
Escape characters
PowerShell and the Windows Command Shell both have escape characters (e.g., `
or \
, depending on the context, and ^
, respectively) for situations where users may want to prevent special characters from being interpreted by the command shell or PowerShell interpreter. Take the following string, for example:
/u^r^l^c^a^c^h^e^ /f^
You can see that it includes: /urlcache
and /f
. The carets here are escape characters that serve no purpose except to protect this string against potential signature matches.
Associated threats
- Impacket
- SocGholish
- ChromeLoader
The prevalence of this technique is buoyed in part by a pair of prevalent threats, SocGholish and ChromeLoader, which ranked fifth and sixth respectively among our top 10 threats in this report. Both employ obfuscation in different ways at different times, including by leveraging zipped files for payload delivery, which is technically considered obfuscation in ATT&CK. You can read more about ChromeLoader and SocGholish in the Threats section of this report.
take action
Those running Microsoft Defender Antivirus can enable the “Block execution of potentially obfuscated scripts” attack surface reduction rule in either audit or enforcement mode. Enforcement and audit events are logged as event ID 1121 and 1122 in the Windows Defender (Operational) event log, respectively. An ID field with a value of 5beb7efe-fd9a-4556-801d-275e5ffc04cc
will indicate that the obfuscation rule fired.
Visibility
Note: The visibility sections in this report are mapped to MITRE ATT&CK data sources and components.
Process monitoring
Obfuscation is often initiated by cmd.exe
and powershell.exe
commands. In order to gain visibility into the malicious use of obfuscation, you will need to monitor for the execution of these and other processes that might directly leverage obfuscation—or otherwise suggest the use of obfuscation. However, processes alone are not a sufficient data source for observing T1027.
Command monitoring
In tandem with processes, command-line parameters can provide unequivocal proof of the obfuscation techniques described in the analysis section above. It’s worth watching out for the execution of cmd.exe
and powershell.exe
with command-line parameters that are suggestive of suspicious obfuscation, whether that’s conspicuously garbled strings of seemingly meaningless characters or commands that indicate the use of one or more of the obfuscation methods described above.
File monitoring
The ATT&CK description for T1027 explicitly states that “Adversaries may also use compressed or archived scripts, such as JavaScript.” As such, file monitoring may be a useful data source for observing obfuscated files or information in the form of payloads hidden within ZIP files.
Collection
Note: The collection sections of this report showcase specific log sources from Windows events, Sysmon, and elsewhere that you can use to collect relevant security information.
Sysmon Event ID 1: Process creation
Very similar to the Windows event described above, Sysmon process creation events log process starts and corresponding command lines, offering a high level of visibility into the encoded PowerShell activity we frequently detect.
Sysmon Event ID 11: FileCreate
File creation events are a useful source of telemetry if you want to keep an eye on adversaries attempting to conceal malicious payloads within ZIP files.
Windows Security Event ID 4688: Process creation
Windows Security Event Log Event ID 4688 with command-line argument capture enabled is a great source of data for observing and detecting malicious use of obfuscation. So too are Sysmon and EDR tools, most of which will collect data that is integral to analyzing obfuscated files or information: process execution and command lines.
Windows Security Event ID 1101 Antimalware-Scan-Interface (AMSI)
Designed to be consumed by security vendors, AMSI telemetry offers visibility into on-disk and in-memory execution of PowerShell and other scripting languages like VBScript, JScript, and WMI, to name a few. Many forms of obfuscated code have varying layers of obfuscation where the innermost layer is often minimally obfuscated or not obfuscated at all. AMSI telemetry can offer insight into each layer at runtime as it is gradually deobfuscated.
AMSI events are not surfaced via Windows event logging, but they may be accessed through Event Tracing for Windows (ETW). We covered AMSI in depth for the Better Know a Data Source blog series.
Note: Beyond alerting on apparently encoded content, consider leveraging a tool—like CyberChef for example—that is capable of decoding encoded commands.
Endpoint Detection (EDR) and Response tools
Many EDR platforms collect telemetry from the data sources listed above and more. A good EDR provides deep visibility into endpoint activity, and offers great value for this and other techniques that manifest in process and command execution.
Detection opportunities
We’ve got 76 detection analytics that look for obfuscation of one type or another. While the analysis section covered many variations of obfuscation, we’ll focus our detection suggestions on just those we observe with a degree of regularity. Some of these analytics overlap with the detection sections of our PowerShell and Windows Command Shell analysis.
Note: These detection analytics may require tuning.
Detecting Base64 encoding
If you’re looking to detect malicious use of Base64 encoding, consider monitoring for the execution of processes like powershell.exe
or cmd.exe
along with command lines containing parameters like ToBase64String
and FromBase64String
. The following simple pseudo-analytic might help you find malicious obfuscation:
process == ('powershell.exe' || 'cmd.exe')
&&
command_includes ('base64')
PowerShell -EncodedCommand
switch
Use of the -EncodedCommand
PowerShell switch represents the most common form of obfuscation that we detect across the environments we monitor. It might also be the detection analytic that we’ve discussed most often over the years in past Threat Detection Reports and other Red Canary content. You can detect the -EncodedCommand
switch with the following logic:
process == powershell.exe
&&
command_includes [any variation of the encoded command switch]*
*Note: the -EncodedCommand
switch can be shortened to -e
, -ec
, and any sequence of letters up to “encodedcommand”
Escape characters
Consider alerting on command lines containing excessive use of characters associated with obfuscation, like `^= % ! [ ( ;
. This can be a little tricky to engineer, but the following pseudo-analytic is an effective illustration of what you might consider looking for:
process == cmd.exe
&&
command_includes [excessive use of the following] ('^' || '=' || '%' || '!' || '[' || '(' || ';')
ZIP file spawning JavaScript
We’ve detected high volumes of obfuscation this year looking for apparent phishing schemes where adversaries conceal JavaScript payloads in ZIP files and write them to the users
and temp
directories.
process == 'wscript.exe'
&&
command_includes ('users' && 'temp' && '.zip’ && '.js')
&&
has_external_netconn
Weeding out false positives
Since obfuscation is used by adversaries and administrative tasks alike, detection analytics for obfuscation are false positive prone. The best way to prevent false positive alerts on this type of behavior is to not depend on it as a sole indicator of malicious activity. Organizations should explore enabling PowerShell logging and execution policy restrictions set via Group Policy Object (GPO), which can’t be overridden at the command line, and enable enforcement of signed script execution and constrained runspaces.
Testing
Start testing your defenses against Obfuscated Files or Information using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.
Daniel Bohannon’s DOSfuscation also warrants mentioning here because the tool enables defenders to randomly generate thousands of uniquely obfuscated sample commands to test and tune their detection capabilities against these techniques.
Getting started
View atomic tests for T1027: Obfuscated Files or Information. In most environments, these should be sufficient to generate a useful signal for defenders.
Run this test on a Windows system using PowerShell:
$cmDwhy =[TyPe]("{0}{1}" -f 'S','TrING') ; $pz2Sb0 =[TYpE]("{1}{0}{2}"-f'nv','cO','ert') ; &("{0}{2}{3}{1}{4}" -f'In','SiO','vOKe-EXp','ReS','n') ( (&("{1}{2}{0}"-f'blE','gET-','vaRIA') ('CMdw'+'h'+'y'))."v`ALUe"::("{1}{0}" -f'iN','jO').Invoke('',( (127, 162,151, 164,145 ,55 , 110 ,157 ,163 , 164 ,40,47, 110 , 145 ,154, 154 ,157 , 54 ,40, 146, 162 , 157,155 ,40, 120, 157 ,167,145 , 162 ,123,150 ,145 , 154 , 154 , 41,47)| .('%') { ( [CHAR] ( $Pz2sB0::"t`OinT`16"(( [sTring]${_}) ,8)))})) )
What to expect
The above is an obfuscated version of the following PowerShell command built with Invoke-Obfuscation
:
Write-Host 'Hello, from PowerShell!'
Useful telemetry will include:
Visibility | Telemetry | Collection |
---|---|---|
Visibility : Process monitoring | Telemetry: A | Collection : EDR, Sysmon Event ID 1, and Windows Event ID 4688 should collect relevant telemetry. |
Visibility : Command monitoring | Telemetry: Command-line logging will capture the context of what is executed. | Collection : EDR, Sysmon Event ID 1, and Windows Event IDs 4688 and 4104 should collect relevant telemetry. |
Review and repeat
Now that you have executed one or several common tests and checked for the expected results, it’s useful to answer some immediate questions:
- Were any of your actions detected?
- Were any of your actions blocked or prevented?
- Were your actions visible in logs or other defensive telemetry?
Repeat this process, performing additional tests related to this technique. You can also create and contribute tests of your own.