By Jeffrey J. Guy and Rico Valdez
We have long associated malware with files on disk, so malware that works differently is earth shattering to some. At Bit9 + Carbon Black, we just shrugged.
“Just another ‘new’ technique circumventing traditional signature-based file protections, focused narrowly on stopping malware at the moment of compromise,” we thought. “It happens all the time.”
We’ve long recognized compromise is inevitable. Worse, as attackers move laterally through your infrastructure, they are “living off the land,” using built-in system administration capabilities such as Windows Terminal Services, psexec and Windows networking. There is no malicious software to detect, thus there is nothing to stop.
Carbon Black’s ability to continuously record all endpoint activity gives you ample opportunity to detect these behaviors, notify your team and review them in seconds.
The Bit9 Security Platform’s customizable prevention capability enables your team to control precisely what is (and is not) allowed to run on your systems. In this regard, “Poweliks” is the same as every other piece of malware. Our systems required no signature updates for this because we already give you the tools you need to detect, respond and prevent Poweliks compromises.
Poweliks made headlines because its code is stored encoded in the registry with value names obfuscated to confuse regedit and other tools. These keys are nothing unusual: it’s the standard malware “goto” HKCU\Software\Microsoft\Windows\CurrentVersion\Run key, whose contents are executed at each user login.
Carbon Black records both writes of first-stage installer to the registry keys, both the default Run key and the obfuscated value name that confuses regedit.exe:
Carbon Black also records the creation and execution of an alternate data stream on itself, the first stage payload:
That process only does one interesting thing: it deletes the first-stage payload:
The first-stage payload also has a second child process, rundll32.exe.
This is the process tree that got so much attention, because these are typical system administration tools whose command lines include malicious scripts stored in the registry. In the Carbon Black console, it’s pretty clear what’s happening.
Here’s the command line to rundll32.exe:
That command line is the un-encoded version of what is in the HKCU\…\Run key. It’s executed by the first-stage installer on initial execution, and executed at every user login by explorer.exe.
Similarly, you can see the command line to powershell.exe, using the Invoke-Expression argument to execute a string, in this case passed via an environment variable:
“c:\windows\syswow64\windowspowershell\v1.0\powershell.exe” iex $env:a
On a new user login, the chain of execution is the same:
The rundll32.exe and powershell.exe command line arguments are the same as above.
The media fawned over Poweliks, its use of the registry, and the complex encoding schemes it uses to hide the registry values and their contents. By continuously recording process activity, Carbon Black renders most of that complexity moot.
Right in the Carbon Black console, you can observe the malware activity—even if it occurred weeks ago on a machine halfway across the world.
There are ample opportunities to detect Poweliks and its variants using Carbon Black’s powerful query engine (pdf). If you’re a Carbon Black user, you probably already have ideas after reading the analysis above.
Here are some query strings to get you started:
powershell launched with the Invoke-Expression argument:
rundll32 launching powershell:
powershell launching dllhost:
These are all suitable queries for a typical Windows installation, but they may have unexpected matches in your environment based on your enterprise’s custom applications. Give them a run and see what you find.
On the Bit9 side of the house, we can implement custom rules to watch for, and optionally block, some of these same behaviors. For example, the following custom rule will generate an event any time powershell is launched by rundll32.
Rule type: Execution control
Path or File: powershell.exe
You also can change this to a block rule once you’re comfortable this activity is not normal for your environment. This is a good rule to have in place, as powershell has become a popular target in attacks.
Similarly, you can write a rule around powershell launching dllhost.exe:
Rule type: Execution control
Path or File: dllhost.exe
Analysis completed on a Win7 x64 VM with sample 0181850239cd26b8fb8b72afb0e95eac