In their latest attempts at evading detection, attackers are using Invoke-DOSfuscation a researcher-created framework for disguising malicious commands.
In the escalating cat-and-mouse game between attackers and security vendors one of the fundamental levers on the attackers' side is the use of obfuscation — scrambling or otherwise disguising malicious code to make analyzing or detecting its purpose and intent more difficult. The use of obfuscation can be traced back to the earliest malware campaigns, and as security products have evolved to breakdown obfuscation techniques, new techniques are always quick to take their place.
More recently, an increase in obfuscation techniques specifically used to disguise malicious commands executed through cmd.exe prompted security researcher Daniel Bohannon to explore down a rabbit hole. When he emerged nine months later, he did so with a robust body of research around what he referred to as "DOSfuscation" (command line argument obfuscation), and a framework for generating thousands of uniquely obfuscated sample commands (Invoke-DOSfuscation).
The goal of the research was to raise awareness and enable defenders to develop and test detection capabilities against these techniques. Unfortunately, it appears the research has gained the attention of attackers, too, as there are now instances of the methods and the framework being abused to disguise attacks in the wild.
Examples of DOSfucation being used in the wild
In late July, researchers at G Data identified the use of DOSfuscation in a campaign attempting to spread Emotet, a prolific banking trojan turned downloader for other banking trojans. The campaign was delivered in the familiar form of spam emails with attached Word documents disguised as invoices. As in many other classic cases, the Word documents contained embedded macro (VBA) code designed to launch PowerShell via a command interpreter with the ultimate goal of downloading a second-stage payload.
But when researchers examined that code, things started to get interesting. At first, they thought they had extracted the code incorrectly. It looked like a random collection of characters and spaces.
Code obscured with DOSfuscation methods. Source: G Data
After detailed analysis involving multiple treatments of string and symbol replacement, it became clear the code contained a command line argument to launch PowerShell via cmd.exe and retrieve a payload file from a malicious URL. Researches were then able to examine the payload file and identify it as Emotet.
As adversaries continue to explore and build on these obfuscation techniques and others, it's important for organizations to make sure their security efforts are keeping pace. Whether that involves in-house defenders creating and testing their own detection rules (Bohannon provides tools and samples here), or companies without large in-house security teams implementing (and reevaluating) third party services and solutions, security needs to be continually tuned to avoid falling behind.
Seeing through obfuscation techniques: How Barkly prevents attacks
The escalation of obfuscation techniques is yet another reason why it's crucial to have endpoint security that doesn't just rely on file scanning, but that can identify malicious behaviors and process patterns, as well.
Barkly's Endpoint Protection Platform blocks the Emotet attack examples cited in this post, despite their use of DOSfuscation methods. That's because it's able to identify attempts to launch cmd.exe from Word, and blocks that suspicious behavior before any malicious commands can be successfully executed. No payload retrieval. No infection. No clean up or recovery necessary.
And for companies without dedicated SOC teams, no manual creation and endless tweaking of detection rules needed.
Find out how Barkly’s unique endpoint protection provides it with deeper visibility than any other solution, allowing it to block evasive attacks other solutions miss.Learn more.