Friday, November 30, 2018

Analyzing infected documents

Occasionally, users ask me to take a look at a document (usually .docx or .pdf) that they are unsure of.  It might be that the sender is someone known to them but they weren't expecting a report or an invoice, or perhaps they don't know the sender but the message seems legitimate.  As a part of our security awareness campaigns, I have repeatedly encouraged them to ask.  I'm glad they do.

Other times, it comes to my attention that a user has, or might have, opened a malicious attachment.  In these cases also I need to find out what I'm dealing with.  Is the document malicious?  What does it do if you open it (and Enable Content)?  Does it actually execute code or just link to a phishing site?

My favorite tool for analyzing these documents is https://www.hybrid-analysis.com.  This site makes it very easy to figure out if a document is malicious, analyze its behavior, and identify potential indicators of compromise.  The following is a quick walk-though the highlights some of the information that is provided when you analyze a document on the site.





To start with, simply drag and drop the file into the box or provide a URL, and click Analyze.



You can provide an email for optional notification, or just proceed.  You do have to agree to their terms.  Be very careful if there is any possibility that your document contains PII.  Most of the documents I deal with are (if they turn out to be legitimate) things like invoices that are not confidential (I work in the public sector).



Pick a VM and you're ready to go.


As you can see, the overview will tell you whether this file has been seen before ("Last Sandbox Report" and what percentage of AV programs detect it as malicious.  The AV results were less certain when I ran this document through a couple of days ago (I think it was at about a 10-15% detection rate).  But, what if it's not detected as malicious or only a few programs think so. We should dig in.


Further down, is the sandbox report.  It usually takes 15-20 minutes to get a report back but I've run this file through before so I have a report available now.  Let's click the report on the right and see what we get.



This already looks bad.  My Word document is spawning new processes and making network connections.  Not what I'd normally expect (or want).



This document appears to run a series of PowerShell commands, drops an executable jDY.exe, and creates nirmalahistory.exe.  I don't know what the ultimate purpose is, but I've seen more than enough to know that I don't want anyone to open this.



Further down, I can see that this opening this document resulted in contacting several sites with phishy-looking names.  On the right, I can see that all of them are tagged as malicious by at least some AV engines.




Further down, we can see the actual command lines that are executed by this document.  They appear obfuscated, but we can see what we already knew: it executes a bunch of PowerShell commands.



Under Suspicious Indicators, we can see that the processes accesses the Service Control Manager and appear to be starting a new service.



A little further down we have a handy list of IP addresses that these processes connect to.





And domain names and URLs too.



Near the bottom, we get to see screenshots from the VM that was used to open and analyze the document.  This is very helpful for cases where the document either not malicious or where it links to a phishing site rather than trying to execute code.  If the document is legit, I would expect to see a real invoice, letter, etc.  I can show this to my users and ask them if its something they were expecting.  In the case that it's used for phishing and doesn't execute any code, I might see that the document contains a fake link to Dropbox or Google Drive.


Hover over the right-hand side of the series to scroll right and see additional images.  Click on one to open it.



Here, we see that this document offers the user a pretext for clicking "Enable Content".



Near the bottom we can see all of the files that were dropped as well as the AV scan results for those files.  In this case, the jDY.exe file is identified as Emotet.

MalwareBytes describes Emotet as "a banking Trojan that can steal data, such as user credentials stored on the browser, by eavesdropping on network traffic."  The "banking trojan" part is clear enough.  In the next part, I think they mean to say that it steals credentials from the browser AND grabs network traffic.  They also say "[o]nce Trojan.Emotet has infected a networked machine, it will propagate using the Eternal Blue vulnerability."  Gnarly.  CERT says that "Emotet is an advanced, modular banking Trojan that primarily functions as a downloader or dropper of other banking Trojans."  They indicate that it can spread over SMB but do not mention using EternalBlue or other exploits.  Symantec reports that Emotet has been used to spread Qakbot which uses Mimikatz.

If you wanted to do some additional reverse engineering, this is probably the point at which you'd want to load this into another tool and start analyzing the executables yourself.  For my purposes, I've got more than enough information.

One important thing that I haven't discuss so far is that this tool provides lots of indicators of compromise (IOCs):


  • A process named "nirmalahistory.exe"
  • An executable named "jDY.exe"
  • Several IP addresses and domain names
I could follow up by checking to see if any of my users have reached out to the addresses given here.  If so, they are compromised.  I could also search my EDR tool for the executables named.  I might also check logs for evidence of any new service installations, but there's a lot more noise there.

No comments:

Post a Comment

Understanding Scope in Go

As per my New Year's resolution, I've been learning to program in Go and reading  The Go Programming Language .   On page 141 of the...