Friday, October 21, 2016

Analyzing A Malicious Macro

**DISCLAIMER**
I am not an expert.  I am new to analyzing malware.  I take the best precautions that I know how to do, but that does not make them best practice.  If you decide to try the things in this blog, I am not responsible for what happens.
**

Someone found out that I was a little bit interested in taking a look at how different malware ticks.  So they've been sending me suspicious e-mail attachments.

I have a healthy fear of accidentally infecting my machine.  I would feel horrible if I accidentally infected my machine, and it spread to other devices.  As Mal Reynolds on Firefly says, "Honestly, there might be tears."

I use VMs to do the analysis.  The host machine is used exclusively for ctfs and analysis.  The permissions for the user on the host machine are set so that if the user was owned, the bad guy  wouldn't be able to do much unless he had a privilege exploit or two handy.  I followed the hardening guides on cisecurity.  The host should be on a separate network-either separated by a VLAN, or just physically on a different network.  I prefer a completely different network over a VLAN.  If something goes wrong, I can simply pull the plug if needed.  I make snapshots of the guests before continuing any analysis, and the guests are reverted when the analysis is as complete as my current skill level can achieve.

To begin with, I have Internet Connectivity to download the file I want to analyze.  (This may not be best practice, but it keeps the chance of my host being infected low.)  I don't have a bridged connection with the host.  (There are write-blocking USBs if one would rather transfer dubious files via removable media.  Or, one could use a CD.)  The networking is then disabled.  The guest can't connect to the Internet after that initial download.  VMWare Tools is not installed.  The type of analysis done is static analysis of any code/file that I find.  That means that I don't launch the malware to see what it does.  This limits my capability of finding out exactly what the malware does, but is less risky than dynamic analysis-ie double clicking the malware and letting it run.

My current skill level-I can guess with a certain confidence level that something is malware.  I may not know exactly what it does, but it contains enough indicators like trying to obfuscate the code to bypass antivirus solutions, that I know it is most likely malicious in nature.

I was recently sent an e-mail attachment that was a Word document.  This one was already suspicious because it was in an e-mail that stated that the sender was the IRS.  The e-mail stated that the recipient owed the IRS money and that if they didn't open the attachment and return the information requested therein that the recipient would be in trouble and face jail time or fines.  Tip:  If the IRS contacts you, it won't be in an e-mail.  They would probably call you, send snail mail, and show up at your door.  This may just be a phishing e-mail-an e-mail that isn't malicious in of itself-ie-doesn't own your machine-but designed so that you give the bad guys your important information.

I have a burner e-mail for e-mail attachments that I want to analyze.  Tip:  Major e-mail providers won't even let you download malicious attachments.  If you have a malicious attachment that they know about, they remove it and leave a nice little note in place stating that the attachment was malicious and they removed it for your safety.

I send it to my burner, but I can't always analyze it. Sometimes, it takes a few days for them to detect it, other times it's removed as soon as I get it.  So there is a limited amount of time to get a sample down from an e-mail address.  There are websites that offer malware samples for analysis, but I steer clear of them for now.  I wouldn't exactly consider them trustworthy.

I carefully download it onto my vm.  I prefer not to download it on the host because some malware is capable of opening up all by itself.  Anyone heard of self extracting cabinet files?  This way, I can simply revert back to a clean Snapshot if there is a problem.  If my host is infected I have to remove the OS and completely reinstall it.  It takes a lot more time.

I'm using Remnux to analyze the file.  For those of you that don't know what Remnux is, it's a free Linux distribution that has malware analysis tools on it.  I've also installed SIFT on it.  SIFT is a Linux distribution used to do digital forensics.

If I ever do decide to try to analyze a sample dynamically, I could first install monitoring software on the target OS VM, start the monitoring software, and then take a snapshot before infecting it.  The cool thing about that, is that I can take a snapshot after it's infected as well, and use the snapshot as a memory sample to do memory analysis.  So, not only could I analyze the malware while it's running, but also, while it is not running.  It's difficult to hide stuff when it isn't actively running.  Some malware stays resident in memory while a computer is powered on, so you won't see any processes.  If it is designed well, it won't cause issues with your computer and you won't even know that it is running in the background.  Even if you do see processes, metasploit, a pen-testing tool, has the ability for its exploits to migrate to other processes, so you won't see it's a bad process because it's hidden in the other process.  It'll look normal.  When doing memory analysis, you can see those things because you can actually look into the processes and see where the bad process hooked in.  One problem, which is less of a problem nowadays, thanks to the common business use of vms, some malware won't run in vms.  Another less likely problem:  there are some samples of malware that can break out of the vm and cause havoc on the host machine.  Keeping the vm software up to date is extremely important.

Lenny Zeltser has an excellent blog about malware analysis if anyone is interested in looking it up.  It's at https://zeltser.com  He mentions Didier Stevens for malware analysis tools of pdfs and Word documents.  Some of those tools are already on Remnux.

To analyze this particular sample, I used oledump.py.  I absolutely love it.  You can dump the contents of certain objects.  In this sample, I found macros, and I could dump the code and look at it with a simple command.

oledump.py malicious.doc - shows the objects in malicious.doc
oledump.py -s 1 malicious.doc - shows, specifically, object one of malicious.doc
oledump.py -s 1 -v malicious.doc -shows, specifically, the contents of object one of malicious.doc, in hex and printable characters if there are any

Like other Linux commands, you can redirect it to a file, so that you can analyze it with strings or a command line text editor.

oledump.py -s 1 -v malicious.doc > malicious.txt

The sample had 3 macros.  It had a typical antivirus bypass method in the code.  Basically it uses string functions to build whatever it needs.  It also had similar lyrics to Genie In A Bottle as comments.  They didn't hide what libraries they were going after either.  Really guys?  You're that lazy?  Kernel32, User32, Nt.dll, etc.  So, I could see that it targeted Windows Machines.  It even had an If Statement in there to see if a machine was Windows 64 bit or not.  So, it could theoretically handle Windows 64 bit machines.  In another object, I saw a bunch of data that I'm fairly certain was encoded.  I also saw what I believe was a decoding function named "crusty".  (I think that "crusty" might be a decoding function because it is the only readable text in that data that I think is encoded.)

I thought that I could use Excel to find out what those string functions did.  I'm sure that those functions in particular where not malicious because they built strings and put them into variable names.  Those variable name values were the names of the methods that did what the malware wanted it to do.  So, as long as I didn't copy every single function, and only copied the string functions, I'm not likely to infect myself with variables being populated by string functions.  I just print the variable names to see what they are.  Debug.Print variable  (I'm not sure about terminology.  I know what I mean, but it might be confusing to others.)  For instance, instead of naming a method, "Scripting.CreateObject" they would name it "adversity" and build "Scripting.CreateObject" out of string functions and put that value into a variable "adversity".

Didier Stevens already had that idea about using VBA to decode encoded functions of macros that were made with VBA.  He made an Excel Macro & Spreadsheet that decodes encoded data if you copy the decoding function and tell the macro where the decoding function is.  I did not try this because I wasn't exactly sure what the macro that I was examining did.  He warns that a payload may be inadvertently set off if one is not careful.

That was enough analysis for me at this time.  I might analyze it more after I learn more.  I don't want to take the chance of accidentally infecting my machine by being careless.  I may submit it to VirusTotal and see what pops up later.

No comments:

Post a Comment