Skip Navigation
Get a Demo
 
 
 
 
 
 
 
 
 
 

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
 

Analysis Icon

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 equal util.exe, thereby allowing cert%u% to execute certutil.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

 

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.

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 icon

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 Icon

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.

Icon-threat detection

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 Icon

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:
VisibilityTelemetryCollection
Visibility :

Process monitoring

Telemetry:

A powershell.exe process will start.

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.

 
 
Back to Top