We received an advisory from a faithful reader indicating that he had uploaded "a dropper we got blitzed with from a spam campaign today" to ISC. We love us some malware samples, so I got busy. A typical review of the sample (invoice.exe) on a Windows VM gave us the basic behavioral details as seen in this ProcDOT visualization (ProcDOT also rules).

We can see that the invoice.exe process makes two Internet calls, spawns some shells to run reg.exe to create some registry entries, and creates a log file along with replicating itself to mc.exe in the victim user Application Data directory, before hiding itself from visible user APIs. Anubis provides better detail, but of concern was that fact that invoice.exe and mc.exe (same file, same hash) exhibited only one AV detection via Virustotal as this was written (certain to change soon). As such, we don't have much to go from as to what malware family we're really dealing with here.

But wait...Volatility to the rescue. I grapped a memory image from the compromised VM, copied the memory dump to my faithful SIFT 2.14 VM, and issued three simple commands that gave me all I needed to know.

1. vol.py --profile=WinXPSP3x86 connscan -f invoice.raw
2. vol.py --profile=WinXPSP3x86 pslist -f invoice.raw
3. vol.py --profile=WinXPSP3x86 malfind -p 268 -D ~/Desktop/output/  -f invoice.raw

Here's the play by play.

• Step 1 indicated that Process ID (PID) 268 was responsible for an connection to 124.248.205.22 over port 80 in Hong Kong (oh boy, we know this doesn't end well).
• Step 2 indicated that PID 268 belonged to invoice.exe (our intial sample, we're on the right track).
• Step 3 dumped PID 268 to the SIFT desktop as process.0x86372a38.0x400000.dmp

I upload said .dmp file to Virustotal and voila, now we know what we're dealing with. Our faithful reader is the proud owner of a W32.Shadesrat (Blackshades) variant. This is one malware family where they apparently caught the bad guy last year (not before he sold his warez to many a miscreant as is evident here).

Wise man say "What I hear I forget, what I see I remember, what I do with Volatility I understand."

Hope to see you tonight at SANSFIRE 2013 for some Volatility 101 across the full lifecycle of security analytics (penetration testing, monitoring, incident response).

Russ McRee | @holisticinfosec

Download here: http://www.microsoft.com/en-us/download/details.aspx?id=39273

Microsoft blogpost: http://blogs.technet.com/b/srd/archive/2013/06/17/emet-4-0-now-available-for-download.aspx

TJ O'Connor's Nuclear Scientists, Pandas, and EMET Keeping Me Honest, an ISC guest diary posting: https://isc.sans.edu/diary/Nuclear+Scientists%2C+Pandas+and+EMET+Keeping+Me+Honest/15890

For those of you who are new to EMET:

"The Enhanced Mitigation Experience Toolkit (EMET) is designed to help prevent hackers from gaining access to your system. Software vulnerabilities and exploits have become an everyday part of life. Virtually every product has to deal with them and consequently, users are faced with a stream of security updates. For users who get attacked before the latest updates have been applied or who get attacked before an update is even available, the results can be devastating: malware, loss of PII, etc." 

EMET 4.0 features and updates incude:

n is a scan

One of our readers provided an update this morning to the ISC of an ongoing educational/research scan of the Internet that will be expanding to include further ports and protocols.  While I appreciate the effort and reasoning behind the educational/research scans, using the internet at large may not necessarily be the way to go about this, so I'm asking for input and comment.

The value in data taken from scans of the internet is very real, no doubt, and I applaud the organizations for efforts to inform the Internet community they are doing.  The impact to the organizations is the hidden cost in this scanning and classification effort, however, and I am afraid the research institute may be overlooking this fact.  

In almost every organization with an IDS or IPS you will have a person responsible for the review and analysis of the activity.  However not all Security Analysts out there read the ISC or other sources of security information on a daily basis.  So when the security analysis notices unidentified addresses or services, the effort to classify the activity begins.  This may take an hour sometimes, and from my experience time is always the resource we never have enough of.  This is where the cost is incurred by the end user being scanned.   The time spent to identify and update their internal databases.

One last thought: The vulnerability data collected by these scans would be a gem in the wrong hands, much like the compromise of the database compromised earlier this year which contained a catalog of existing vulnerabilities in US hydroelectric dams.

So thoughts your thoughts, is this the best way to do this?  Is it the only way?

tony d0t carothers @t gmail

The Basic Plan

1) Plan and Walk my Exit Route

2) Locate Nearest Fire Extinguisher (if one is installed, not so often anymore)

3) Pick a spot for key items in hotel (Tablet, Laptop, Cell Phone)

These are simple things that if walked through once should aid a late night wake up call from a fire alarm when that collides with drowsiness.

What Happened

At 1222AM an alarm sounded at my hotel in San Francisco and I executed basic plan for egress. I was stunned at how few people were leaving hotel rooms. Some had heads peaked out of rooms looking to see if perhaps others were leaving or if they maybe "had" to leave?

When I got down stairs (Yes stairs, I did see one person staring at the elevator) this is what I was met with:

T+5 min

After about 45 minutes and hotel staff walking the floors and then instructing everyone to wait in the lobby, this was the result:

T+45min

So the moral of this story is have a plan. Even though this was most obviouly a false alarm, I always treat them as if they are real.

Signing off from DC SANSFIRE 2013!

Richard Porter

@packetalien richard at isc dot sans dot edu