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
- escape characters
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 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:
+ operator combining string values
-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
- String interpolation enables another form of evasion by allowing adversaries to set values such that
u\ can equal
util.exe, thereby allowing
cert%u% to execute
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:
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
+ 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
Invoke-Expression in the command line.
PowerShell and the Windows Command Shell both have escape characters (e.g.,
\, 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:
You can see that it includes:
/f. The carets here are escape characters that serve no purpose except to protect this string against potential signature matches.
The prevalence of this technique is buoyed in part by a pair of prevalent threats, Gootloader and SocGholish, which ranked fourth 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 Gootloader and SocGholish in the threats section of this report.