BSides Augusta Talk

Earlier this month I had the privilege of speaking at BSides Augusta.  I gave a lightning talk on working with the Viper Framework for static analysis.

Here's the talk:

I also released the module and API scripts I wrote for the talk.

I cannot say enough about the talent and quality technical content in the BSides Augusta talks.  This is easily a "Top 5" defensive security event.  I seriously have no idea how I managed to sneak into this speaker lineup.  Definitely going back next year.

GrrCON 2012 Forensics Challenge Walkthrough

This is a walk-through of the GrrCON 2012 Forensics Challenge that was designed by Jack Crook (@jackcr). Special thanks to Jack for making it so much fun and challenging!

• You can read about the challenge here.
• You can download the challenge files from the links here.
• You can watch Jack's MiSec presentation on the challenge here.

1. How was the attack delivered?

Open out.pcap in Wireshark, find first TCP session, and follow the TCP stream.

Oh, look! A file that ends in *.doc.exe, that can't be good! Note the "MZ" file magic number and "This program cannot be run in DOS mode" text -- sure signs that this is a Win32 executable file.

Answer: HTTP download of http://66.32.119.38/tigers/BrandonInge/Diagnostics/swing-mechanics.doc.exe

2. What time was the attack delivered?

In Wireshark, find the HTTP GET request ACK packet from the stream we just looked at. In the Frame section of the packet, locate the timestamp.

Answer: Apr 27, 2012 22:00:59


3. What was that name of the file that dropped the backdoor?

Looking at the same HTTP GET request in Wireshark, what was the name of the file from the URL?

Answer: swing-mechanics.doc.exe

4. What is the ip address of the C2 server?

In Wireshark, clear the current TCP stream filter, and browse through the packets.  As the HTTP session with the malware dropper ends, we see a new outbound connection to TCP port 443 from our victim. The destination address is the command & control (C2) server for our back door.

Answer: 221.54.197.32

5. What type of backdoor is installed?

Run foremost to extract the Win32 EXE file we found in the first question: 

foremost -t exe out.pcap

Foremost will create an output directory with a subdirectory named 'exe' that should contain our backdoor. Now upload the file to VirusTotal. You should see that VirusTotal has already scanned this file. When I did it on 10/6, the last scan date was 9/28, the first day of GrrCON. :)

Answer: Poison Ivy

6. What is the mutex the backdoor is using?

This is the first answer to the challenge you have to work hard for. In order to do this the right way, you must use the memory dump to identify which process initiated the connection to the C2 server, then use its PID to find the base address and memory range, then use that to match any mutexes for that range.  (You can cheat here and Google search Poison Ivy mutexes and see if any of them are present in the mutantscan output, too, but as I said, that's cheating. :))

First, find the process that's connecting to the C2 from question #5. 

vol.py -f memdump.img connscan |grep 221.54.197.32

We see it's the process at PID 1096. So now we need find out what process it is and, more importantly, it's base address and memory range.

vol.py -f memdump.img psscan |grep 1096

Uh-oh, that's explorer.exe, isn't it? Process injecting basterds! The base address of our pwned process is 0x0214a020. Any mutexes we find in that range are of interest to us.

vol.py -f memdump.img -s mutantscan |grep 0x0214

There happens to be a funny-looking mutex close to our base address. It's not a guarantee that this is the answer we're looking for, but a quick Google search for "Poison Ivy mutex" validates the finding.

Answer: ")!VoqA.I4"

7. Where is the backdoor placed on the filesystem?

To answer this question, we'll examine the SleuthKit file (compromised.timeline) that Jack was kind enough to include in this challenge. We'll start by looking around the time that the backdoor was downloaded (4/27/12, 22:00:59) in question #2 and working forward. Also, we'll want to look for any files that are the same size as the one we extracted from the pcap file with foremost (8,192 bytes) in question #5.

(Note: If you got stuck here at GrrCON because you assumed that the filesystem time and the packet capture time were perfectly in sync, you learned the most valuable lesson there is in DFIR. There is always drift in timestamps between sources. Unfortunately, you learned it the hard way.)  

At 21:59:20 on 4/27/12, we find the prefetch temp file for the swing-mechanics.doc.exe file, and immediately after it, another file that matches the size of that file from our pcap being written to c:\windows\system32\svchosts.exe.  

(Note: There is a svchost.exe file in %systemroot%\system32 on WinXP and Win7, but there is no svchosts.exe, another clue that this is not legit.)

Answer: C:\WINDOWS\system32\svchosts.exe

8. What process name and process id is the backdoor running in?

Now, if you got this far, but cheated at question #6 instead of doing the work, you may have run the volatility pslist module, saw svchost.exe, and given the wrong answer. Oops! Cheaters never prosper. We already know that the right answer is explorer.exe and its PID is 1096.

Answer: explorer.exe 1096

9. What additional tools do you believe were placed on the machine?

Back to where we left off in question #7. Keep working forward in the SleuthKit timeline, and...

That's weird. Prefetch files indicate a program launch. Somebody ran net.exe, ipconfig.exe, and ping.exe. Likely our attacker testing network connectivity. ;-) But wait! There's more!

One thing DFIR will do to you is make you something of an expert on the names of files and folders that live within C:\WINDOWS, and, well, this doesn't look right for a lot of reasons. And when we see a file named sysmon.exe (which normally is in \WINDOWS\system32) created in this folder, and it's the same size as our binary from question #5 (8,192 bytes), we know we're looking at more bad stuff.  So in addition to a backup copy of our backdoor, there is a text file of some kind and four additional executables named f.txt, g.exe, p.exe, r.exe, and w.exe.

You can also find the handles to these files in memory with volatility as well:

vol.py -f memdump.img filescan |grep -i svchosts.exe
vol.py -f memdump.img filescan |grep -i systems

Answer: g.exe, p.exe, r.exe, w.exe, and sysmon.exe

10. What directory was created to place the newly dropped tools?

Answer: C:\WINDOWS\system32\systems

11. How did the attacker escalate privileges?

We can assume from the work we did in #9 and #10, that those binaries aren't copies of calc.exe, so likely one of those was used for privilege escalation. 

It would be great if we could extract them from the memory image, but since we didn't see them when we used the volatility psscan module, our chances aren't very good. Maybe we can find the command syntax that was used and get an idea of which tool was used to do what?

vol.py -f memdump.img cmdscan

Well, that looks like an FTP command mixed in with Jack creating the memory dump we're analyzing, which is interesting, but not what we're looking for. Yet.

(Note: There's a good point to be made here about how by gathering the evidence, evidence was also destroyed. In the process of copying down and running mdd, Jack also overwrote most of the cmd.exe history that we are interested in for this question.)

So, no easy win to be had here. Maybe we can find what we're looking for in strings. We'll use strings and the volatility strings module to pull all of the strings >5 in length out of our memory image and see if we can find anything in there. By looking at the SleuthKit timeline file, we see that w.exe was the first of the suspicious binaries to be launched first, so we'll look for that in particular.

strings -n 5 -t o memdump.img >strings.txt
vol.py -f memdump.img strings -s strings.txt >vol-strings.txt
grep w\.exe vol-strings.txt

Bingo! Those command line arguments are the username, domain name, NTLM hash, and program to run for a pass the hash attack tool of some sort. So now our attacker is running cmd.exe as Administrator. Possibly for the whole COMPANY-A domain.  

If this is your network, this is where you excuse yourself to put on clean shorts.

Answer: pass-the-hash attack

12. What level of privileges did the attacker obtain?

See above.

Answer: Administrator

13. How was lateral movement performed?

Once we understand that the attacker has become COMPANY-A\Administrator on what is probably an Active Directory domain controller, they can go wherever they want. Let's look for hostnames that aren't dc01.company-a.com and see if they did anything interesting there.

grep -i \.company-a\.com vol-strings.txt

In addition to our own hostname, we see the following:

dc01.company-a.com
res-lab02.company-a.com

If we look back to when we ran the volatility connscan plugin for question #6, we saw a bunch of NetBIOS and LDAP connections to 172.16.150.10, which is dc01.company-a.com. That's pretty much a tell-tale sign that dc01 is the COMPANY-A domain controller. Which means our attacker is in fact a domain admin, and can pivot freely onto dc01 and anything else he wants. Maybe he'll do something like map a drive later. Who knows?

Answer: Credential re-use as Administrator

14. What was the first sign of lateral movement?

Now that I think of it, was there anything from 172.16.150.10 in the pcap file?

ssldump -n -r out.pcap

You can do this in Wireshark, too, but one trick I wanted to show off is ssldump's ability to summarize all of the TCP sessions in a pcap file. Oh, and it looks like dc01 is also phoning home to the C2 server. Hope you packed two pair of clean shorts.

Answer: Well, I saw the C2 traffic from dc01 in the pcap file before any of the other evidence, so that's my answer.  

(Note: I think the login to the domain controller as Administrator from a workstation, which came first, should also be caught by the security ops team if they are monitoring the security EventLog on the domain controllers. (Which they should be!))

15. What documents were exfiltrated?

For this one, we had to wander around in the vol-strings.txt file we made to put the pieces together:

less vol-strings.txt

So I admit, this is a bit of a guess, but all of this looks suspicious to me. Here we have a set of files that look like the kinds of things we would want to exfiltrate. Then not that far away, we have a net use mapping a drive to dc01, then making a local directory named "1" (if you look around some more, you discover it's C:\WINDOWS\system32\systems\1). After that, the files from the shared drive are copied to that folder, and that folder is compressed in a rar file and password protected. Then an FTP command is made. That looks like data exfiltration to me.

Answer: confidential1.pdf, confidential2.pdf, confidential3.pdf

(Note: You will see later that I'm close, but managed to miss about half of the files.)

16. How and where were the documents exfiltrated?

Answer: FTP to 66.32.119.38

17. What additionl steps did the attacker take to maintain access?

Unless I missed something (which is actually quite likely), we already talked about this in question #14.

Answer: Installed Poison Ivy RAT on dc01

18. How long did the attacker have access to the network?

So, there are two possible answers Jack is looking for. There's the cynical defeatest answer, "Clearly as long as he wanted." Or there's the specific answer whereby we look at the time from the start of the first C2 connection to the end of the data exfiltration. For that, we fire up Wireshark:

The first screen is the first packet of the first C2 connection, when our attacker actually got control of the first victim system. The second screen has the filter tcp.flags.fin == 1 applied to prove a point. The last packets in the pcap file are ACKs for the C2 connections to both 172.16.150.20 and 172.16.150.10 (res-lab01 and dc01 respectively).  The FTP connections complete at 22:13:26, but the C2 goes on, likely past the end of the file.

Answer: 12 minutes, 21 seconds (or indefinitely)

19. What is the secret code inside the exfiltrated documents?

To get at the secret documents, we need to recreate our own copy of the encrypted rar file used for exfiltration, then decrypt it, extract the files, and view them. Fortunately, we already know everything we need to get this done.

First, extract the rar file from the pcap.

foremost -t rar out.pcap

Now, extract the files. We'll need the password, but we caught that in the volatility strings we sifted through for question #15.

unrar x -pqwerty 00002134.rar

Note the bottom of the screenshot there. Jack's got an evil sense of humor. Those aren't even PDFs! But that is in fact an OpenOffice file.

Answer: 76bca1417cb12d09e74d3bd4fe3388e9

20. What is the password for the backdoor?

Whilst reading the article we Googled for about Poison Ivy mutexes for question #6, we also learned that Poison Ivy doesn't typically use packers or cryptors, and that the C2 server and password are coded in the binary file. I wonder if they'll stick out like a sore thumb...

strings 00000002.exe

We totally recognize that IP address as the C2 server from question #4. You'll never guess Jack's favorite baseball team.

Answer: tigers

If you made it this far, thanks for reading. Hope you liked it. Oh, and your reward for reading the whole thing: In case you didn't catch it, this challenge is essentially a mirror of the attack on RSA that led to the theft of their token seed data files in 2011. When I made that realization, it gave me lulz. Jack, you're the man! :)

One more bonus! Even though it wasn't one of the challenge answers, here's the spear-phish that started the whole thing:

Brandon,
I have been watching you swing for the last few weeks. I believe I have come up with a major break through in your mechanics. If these adjustments are made I believe you will be back up in the bigs and batting .280 within no time. Please review the attached document before our next hitting session. Here
Regards,
Lloyd McClendon

Snort Signatures for New Koobface Variant

The first rule is actually how we caught the first incident. The binary is served on non-standard HTTP ports via fast-flux servers. It's a signature we've had in place for years.

alert tcp $HOME_NET any -> $EXTERNAL_NET !80 (msg: "LOCAL .exe file download on port other than 80"; flow:established; content: "GET"; depth:4; content: ".exe"; nocase; classtype:misc-activity; sid:9000160; rev:1;)

And these are designed to catch the bot HTTP checkins we've seen so far. This is likely to be more of a whack-a-mole effort as we've already seen the checkin URL format change once.

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL Koobface action=fbgen checkin"; flow:to_server,established; content:"POST"; content:"/.sys/?
action=fbgen"; nocase; classtype:trojan-activity; sid:9000220; rev:1;)

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL Koobface go.js checkin"; flow:to_server,established; content:"POST"; content:"/go.js?"; nocase; classtype:trojan-activity; sid:9000221; rev:1;)

Security Metrics and Data Visualization

I've just finished compiling the security incident handler case statistics for 2009. This is the second year in a row that I've used the same set of metrics, and having two years worth of data has led to some interesting observations about security trends within my employer's environment.

One set of statistics that may be of interest to the general Internet public is the volume of malware cases that we have worked over the past two years.



There are a couple of things worth pointing out in this graph. The first, and perhaps most obvious one, is that there is a drop-off in malware related cases in 2009. Surely, that can't be right? It is, but it's due to implementing some new security technologies in December of 2008. In fact, those countermeasures reduced the number of malware cases we handled in 2009 by roughly 65% compared to 2008. I want to say two things about this. First, this demonstrates the effectiveness of the preventative countermeasures that we employed and confirms the value of those countermeasures. Notice that I'm not saying that it proves ROI. But the bottom line is that it was worth it. The second thing I want to point out about that decline, however, is that it's just a decline. It did not eliminate the problem. In fact, in 2009 we saw malware chip away at other defenses that were highly effective only two years before. And I suspect that, if we do nothing else about it, that those levels will begin to rise in 2010 and regain the same level of frequency we saw in 2008 if not higher. There's a hint of that in the graph towards the end of 2009.

The next thing I want to point out about this graph is the peak frequency. It is consistent. Every three months, there is a spike in malware incidents in our environment. I would love to see statistics from other companies or the Internet at large to see if this is an Internet-wide pattern. I suspect that it is. Despite the new countermeasures, despite the decrease in order of magnitude, the spikes occur like clockwork every third month. That leads me to believe two things. First, I believe that this pattern is driven externally since it didn't deviate, even when our environment changed significantly. Second, I believe that this is no accident. The vendors that produce malware/botnet "kits" are responsible for introducing most of the new exploits and anti-detection capabilities that we see on a regular basis. Their stuff is used more widely than custom malware as well. Therefore, this leads me to believe that there is one large group responsible for the majority of the malware in the wild, and they're on a 90-day release cycle. I've got no intelligence data to support this, but I have a hard time believing that this pattern repeats itself, without exception, for two years straight out of pure coincidence.

Bottom line, this is the kind of useful information that trend analysis can give you, and why metrics are worth gathering and analyzing.

Malware Analysis Toolkit for 2010

Back in 2008 I posted a list of the tools I use for doing malware analysis. The tools I use have changed over time, and rather than just talk about a couple of recent additions, I decided I'd put a current complete list up with links. This is by no means a comprehensive list of malware analysis tools, it's just what I like and use.

Platform

• VMWare Workstation
• The "vulnerable stuff:"
  
• Windows XP
  
• Internet Explorer 7/8
• Firefox
• Acrobat Reader
• Flash Player

General Tools

• Cygwin
• Perl
• Python
  
• Hex Editor Neo
• HashCalc
• IZArc
  

Analysis Tools

• SysAnalyzer / iDEFENSE MAP
  
• GMER / catchme
  
• Multipot
  
• OSAM
• HijackThis
• Startup Control Panel
• HookExplorer
• Sysinternals Suite
• ProcL
• sniff_hit
• Wireshark (run on "Host OS" outside VM)
  

Binary Tools

• Mandiant Red Curtain
• OllyDbg 1.10
  
• Various OllyDbg plugins
  
• PEiD
• RDG Packer Detector
• pefile / packerid.py
  
• ImportREC

JavaScript & HTTP Tools

• SpiderMonkey (Didier Stevens mod)
• ieget.sh script
• crap2shellcode.pl
• Console2 Firefox plugin
• NoScript Firefox plugin
  

PDF & Flash Tools

• pdf-parser.py
• pdftk
  
• SWFTools
• Sothink SWF Decompiler

Web Sites as Tools

• Wepawet
• VirusTotal
• CWSandbox
• Comodo Instant Malware Analysis
• Malware Database
  
• MalwareURL
  

Reversing JavaScript Shellcode: A Step By Step How-To

With more and more exploits being written in JavaScript, even some 0-day, there is a need to be able to reverse exploits written in JavaScript beyond de-obfuscation. I spent some time this weekend searching Google for a simple way to reverse JavaScript shellcode to assembly. I know people do it all the time. It's hardly rocket science. Yet, I didn't find any good walk-throughs on how to do this. So I thought I'd write one.

For this walk-through, I'll start with JavaScript that has already been extracted from a PDF file and de-obfuscated. So this isn't step 1 of fully reversing a PDF exploit, but for the first several steps, check out Part 2 of this slide deck.

What you'll need:

1. A safe place to play with exploits (I'll be using an image in VMWare Workstation.)
2. JavaScript debugger (I highly recommend and will be using Didier Stevens' modified SpiderMonkey.)
3. Perl
4. The crap2shellcode.pl script, which you'll find further down in this post
5. A C compiler and your favorite binary debugger
   

I'll be using one of the example Adobe Acrobat exploits from the aforementioned slides for this example. You can grab it from milw0rm.

Step 1 - Converting from UTF-encoded characters to ASCII
Most JavaScript shellcode is encoded as either UTF-8 or UTF-16 characters. It would be easy enough to write a tool to convert from any one of these formats to the typical \x-ed UTF-8 format that we're used to seeing shellcode in. But because of the diversity of encoding and obfuscation showing up in JavaScript exploits today, it's more reliable to use JavaScript to decode the shellcode.

For this task, you need a JavaScript debugger. Didier Stevens' SpiderMonkey mod is a great choice. Start by preparing the shellcode text for passing to the debugger. In this case, drop the rest of the exploit, and then wrap the unescape function in an eval function:



Now run this code through SpiderMonkey. SpiderMonkey will create two log files for the eval command, the one with our ASCII shellcode is eval.001.log.



Step 2 - crap2shellcode.pl
This is why I wrote this script, to take an ASCII dump of some shellcode and automate making it debugger-friendly.


---cut---

#!/bin/perl
#
# crap2shellcode  - 11/9/2009 Paul Melson
#
# This script takes stdin from some ascii dump of shellcode
# (i.e. unescape-ed JavaScript sploit) and converts it to
# hex and outputs it in a simple C source file for debugging.
#
# gcc -g3 -o dummy dummy.c
# gdb ./dummy
# (gdb) display /50i shellcode
# (gdb) break main
# (gdb) run
#

use strict;
use warnings;

my $crap;
while($crap=<stdin>) {
  my $hex = unpack('H*', "$crap");

  my $len = length($hex);
  my $start = 0;

  print "#include <stdio.h>\n\n";
  print "static char shellcode[] = \"";

  for (my $i = 0; $i < length $hex; $i+=4) {
    my $a = substr $hex, $i, 2;
    my $b = substr $hex, $i+2, 2;
    print "\\x$b\\x$a";
  }
  print "\";\n\n";
}

print "int main(int argc, char *argv[])\n";
print "{\n";
print "  void (*code)() = (void *)shellcode;\n";
print "  code();\n";
print "  exit(0);\n";
print "}\n";
print "\n";

--paste--

The output of passing eval.001.log through crap2shellcode.pl is a C program that makes debugging the shellcode easy.



Step 3 - View the shellcode/assembly in a debugger
First we have to build it. Since we know that this shellcode is a Linux bindshell the logical choice for where and how to build is Linux with gcc. Similarly, we can use gdb to dump the shellcode. For Win32 shellcode, we would probably pick Visual Studio Express and OllyDbg. Just about any Windows C compiler and debugger will work fine, though.

To build the C code we generated in step 2 with gcc, use the following:

gcc -g3 shellcode.c -o shellcode

The '-g3' flag builds the binary with labels for function stack tracing. This is necessary for debugging the binary. Or at least it makes it a whole lot easier.

Now open the binary in gdb, print *shellcode in x/50i format, set a breakpoint at main(), and run it.

$ gdb ./shellcode
(gdb) display /50i shellcode
(gdb) break main
(gdb) run

Two-For-One Talk: Malware Analysis for Everyone

These two mini-talks were originally going to be blog posts, but I needed a speaker for this month's ISSA meeting. So I volunteered myself. Here are the slides.

Two-For-One Talk: Malware Analysis for Everyone

View more presentations from pmelson.

SecureWorld Expo Slides

Earlier this month I gave a talk at SecureWorld Expo Detroit on malware analysis. The goal of the talk was to discuss the state of malware and tools for people who aren't ready to go to town with a debugger. Unfortunately, to put it on SlideShare, I had to replace the cool Camtasia videos with lame screen shots.

Malware Analysis Made Simple

View SlideShare presentation or Upload your own.

A Conversation With My Wife

My wife was at her mother's tonight when she caught me on GMail chat. This is the log of that chat, unedited:

Jessica: boo!

me: hey there

Jessica: hey baby!
Just looking at my moms task mamanger, she has a ton of stuff running
inlcuiding a bunch of exe file

me: that's all you should see in task manager - exe files

Sent at 10:28 PM on Tuesday

Jessica: how amobile deviceservice.exe, alg.exe, msmsgs.exe, searchprotection.exe, jusched.exe, E-S10IC1.exe
all of these are listed under "Administrator"

me: some of those are fine
type them into google
liutilities.com
searchprotection.exe sounds suspicious
don't log into the bank or anything

Jessica: why would there be 4 svchost.exe's?

me: that's typical

Jessica: or services.exe
winlogon.exe

me: both fine

Jessica: csrss.exe

me: also fine

Jessica: smss

me: seriously
google

Jessica: mDNSR

me: that sounds suspicious

Jessica: I don't need no stinkin google, I have you
:)

me: meh
Sent at 10:33 PM on Tuesday

Monkey-Spider

It's been awhile since I've covered anything to do with honeypots or honeyclients. But it's also been awhile since anything new came along.

Via Thorsten Holz at honeyblog: Sicherheit'08: "Monkey-Spider: Detecting Malicious Web Sites with Low-Interaction Honeyclients"

Monkey-Spider, not to be confused with SpiderMonkey, is a new honeyclient from Thorsten, Ali Ikinci, and Felix Freiling. Like HoneyC, it's a crawler-based client that detects web-based, client-side attacks. It was presented at Sicherheit in Germany in April. Fortunately, the whitepaper and documentation are in English.

After reading the whitepaper and playing with the code a little, the thing that occurs to me is that, while this is very cool, and still somewhat useful, what I really want for operationalizing a honeyclient in my enterprise is the ability to seed the honeyclient from firewall/proxy logs. That way the honeyclient is analyzing my web traffic, not off looking for random malicious sites to add to already big blacklists.

Game Theory and Mac Malware

Cloudmark's Adam J. O'Donnell wrote a fascinating article which uses game theory to predict the tipping point for mass malware attacks on Mac OS X.

It's very hard to construct a game that can accurately represent an uncontrolled environment like the one that malware and botnets currently exist in - and to his credit, Adam fully acknowledges this. But Adam's article is great for two reasons.

First, I think that his estimate of Mac's needing to break 17% market share before they become worthwhile to malware authors isn't too far off. And second, the game he's constructed is a great model for risk-based analysis of a partially unknown threat environment (which is a fancy way of saying how likely you are to be pwned in the future).

I so often find myself ranting about infosec articles and papers that fail at basic math, let alone reasonable science, that it's nice to see something of this quality hit the trade press. Thanks, Adam.

List of Malware Analysis Tools

Update: There is an updated version of this list of tools posted to my blog here.

If you're a company that's big enough to have a security team, then you already know that client-side vulnerabilities are your biggest external attack surface. And the most common form of exploit is a drive-by download attack that drops a bot or other malware on your client. While we wait for the necessary paradigm shift in malware prevention to come along and replace ineffective AV scanners, we're stuck investigating suspicious web sites and binaries to determine their intent and impact. Part of being able to do these investigations is putting together an environment in which to analyze these web sites and binaries safely. Here's what I have done.

The first step is to build a virtual machine with VMware, VirtualPC, or whatever you prefer. It should be as similar to your corporate image as you can make it, but it should not be on your domain. Also, if you select VMware Server, do not install VMware Tools into the VM. Sure it makes things easier, but it can also make it easy for malware to determine that it's in a VM and prevent it from running. I would also recommend installing your company's AV scanner, but disable real-time scanning by default.

Once you've created your VM, you need add some tools to make analysis possible. Here's the list of stuff in my VM.

Cygwin
- Didier Stevens' SpiderMonkey
- pefile
- Jim Clausing's packerid.py
- My ieget.sh
- Mozilla rhino debugger

GMER
catchme

Mandiant Red Curtain

OSAM Autorun Manager
Mike Lin's Startup Control Panel
HiJackThis / StartupList / ADSSpy

HashCalc

HHD Free Hex Editor

OllyDBG (also: Immunity Debugger)
Plugins:
- AnalyzeThis
- FindCrypt
- Hide Debugger
- OllyDump
- OllyFlow
- OllyDbg PE Dumper

ImportREC

iDEFENSE
- MAP
- SysAnalyzer
- HookExplorer
- SniffHit
- PEiD

SysInternals
- AccessEnum
- autoruns
- Filemon
- procexp
- psexec
- psfile
- psgetsid
- Psinfo
- pskill
- pslist
- psloggedon
- psloglist
- pspasswd
- psservice
- psshutdown
- pssuspend
- Regmon
- RootkitRevealer
- tcpvcon
- Tcpview

Firefox (JavaScript Console mod)

Also, having links to VirusTotal and CWSandbox in your VM is a good idea.

Cool Firefox / JavaScript Trick

Here's an easy trick for deobfuscating JavaScript within Firefox. Via BornGeek and Offensive Computing.

1. Launch Firefox and browse to 'about:config'
   
2. Create a new boolean config preference named browser.dom.window.dump.enabled and set it to 'true'
3. Close Firefox. Now run "firefox.exe -console". A console window will open along with the browser window.
   
4. Edit file containing obfuscated JavaScript and replace "document.write" with "dump"
5. Open the file in Firefox.
1. Disable NoScript, Firebug, or other scripting add-ons and reload the file if necessary.
   
6. Switch to the JavaScript Console window. Now you can read the deobfuscated code.

You can do this with Rhino or SpiderMonkey, so it's nothing new. But the setup is really simple and easy to use, so if you've been avoiding the other tools available because they're hard to use, this may be what you've been waiting for.

Frank Boldewin Releases "More Advanced Unpacking - Part II"

Just last month I posted about Frank's first release in this series, along with some other recommended reading. Here's Part II via Offensive Computing. Awesome stuff. Frank is essentially giving away what he could charge thousands for as a BlackHat Training course or something similar. It's exceptionally generous of him to do so. I've been in awe of Frank's malware unpacking skills for a while now, and I hope he continues to release more tutorials.

30-second Malware Gathering Tool

A few months ago I was trying to automate the retrieval and analysis of JavaScript exploits from a site that was designed to target vulnerable browsers. It was reading User-Agent header strings on the server side and only serving exploits to vulnerable versions of IE and displaying ads to everybody else. So my attempts to script the get-and-grep analysis I was doing weren't working with curl or wget. So I wrote this:

#!/bin/sh -f
if [ $1x = x ]; then
echo "Usage: $0 [url]"
exit
fi
/usr/bin/wget -U "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; InfoPath.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)" $1


All it does is pass url to wget while wget uses an IE6 User-Agent string when it makes its request. Nothing fancy, but it was worth the 30 seconds it took me to whip it up.

Building Didier Stevens' SpiderMonkey in Cygwin

Here's one for your malware analysis toolkit. For some time now, I've been using Rhino, Mozilla's Java implementation of JavaScript, to help automate deobfuscation. SpiderMonkey is Mozilla's C implementation of JavaScript, including a shell much like Rhino's.

There are a couple of things that Mozilla's engine doesn't do when it comes to deobfuscating JavaScript. Specifically, you're left to manually convert eval and document.* calls yourself. That's where this really smart guy Didier Stevens comes in. He has a modified SpiderMonkey that solves both of these issues.

So you already know that I like Cygwin for lots of things, including malware analysis. Unfortunately, SpiderMonkey is really only intended to build on Win32 with Visual Studio. However, there are a couple of quick shortcuts you can take to get it to build with gcc in Cygwin. So here we go.

1. Install Cygwin with gcc and standard C libraries.
2. Download and untar Stevens' SpiderMonkey source tarball.
3. In js/src/config/Linux_All.mk find the line that begins with MKSHLIB and change the ld linker syntax by replacing '-shared' with '-r':

$ grep -n MKSHLIB config/Linux_All.mk
50:MKSHLIB = $(LD) -shared $(XMKSHLIBOPTS)

4. Build using make with the following syntax:

$ make -f Makefile.ref OS_ARCH='Linux'

We're essentially lying to make to get it to build as if our Cygwin environment is a Linux box. This is why shared linking breaks. But it should be a non-issue.

5. The make will exit with errors, but if all went well, the JavaScript shell, js.exe, has already been built:

$ cd Linux_All_DBG.OBJ
$ ls -l js.exe
-rwxr-xr-x 1 nobody None 1493267 Dec 27 17:40 js.exe
$ cd
$ cp js/src/Linux_All_DBG.OBJ/js.exe $HOME
$ ./js.exe
js> document.write("oh word!");
js> ^C
$ cat write.log
oh word!

And that's it. Make a copy of the binary for future use and clean up.

Storms

A nasty storm blew threw West Michigan on Sunday and Monday with lots of wind damage. It knocked out power to major chunks of the city, including the airport, which is literally close to home for me. Fortunately, the uptime on my OpenBSD box shows 25 days, so we never lost power (or cable, which is good, because I am trying to Tivo My Name Is Earl reruns that I missed.) So if you're family and you're reading this, we're safe and warm.

And then there are the latest mutations of that ongoing Storm thingy that fortunately doesn't leave people homeless or stranded. It's still annoying, though. You can't help but get the sense that the spammers are all taking advantage of the holidays:





That's 60 new spam messages in my Postini quarantine since Friday. That's not my GMail account, which has closer to 7K, but rather my work-only address which is seldom-published and hardly sees any spam. Additionally, Postini only shows me messages it's not sure about, so that's almost always new variations of spam messages. For me to have 60 in a month is rare, let alone a few days. The dirtbags have been busy.

Tis The Season

Sunday morning I followed up on a case involving a new mass-sploiter. It was interesting - PHP remote file inclusion attack with a hosted exploit that was targeting Windows. Of course, it didn't affect any of the systems it touched on my end, and I decided not to try for the binary. Why not? Because it was Sunday morning, I was at my in-law's house, packing up to go have a late Thanksgiving with my family.

And then it hit me. Get ready. Here it comes. As we head into the holidays, the malware folks are gearing up, hoping to catch us off guard. They've already got the design in place, the new text for socially engineering users and packing & obfuscation tricks to bypass spam filters and AV scanners. They're just waiting. Last winter it was New Year's Eve and then the SuperBowl. The timing of those attacks was no coincidence. This season I expect something similar.

A Message for Digital Flow

I was following up on some suspicious JavaScript content and found this:

//****** Advanced DHTML Popup Pro Version 2.40.096.201.019, Build: 130 ******
// Copyright (c) Digital Flow Software 2005-2006
// The present javascript code is property of Digital Flow Software.
// This code can only be used inside Internet/Intranet web sites located on *web servers*, as the outcome of a licensed Advanced DHTML Popup application only.
// This code *cannot* be used inside distributable implementations (such as demos, applications or CD-based webs), unless this implementation is licensed with an "Advanced DHTML Popup License for Distributed Applications".
// Any unauthorized use, reverse-engineering, alteration, transmission, transformation, facsimile, or copying of any means (electronic or not) is strictly prohibited and will be prosecuted.
// ***Removal of the present copyright notice is strictly prohibited***

And subsequently, this:

Unblockable popups

The popups that are created with Advanced DHTML Popup are not blocked by standard external window blocking software as they are part of the web page and not windows on your visitors desktop.

So, first of all, I would like to say that for as long as your "intellectual" property appears on my network just like a malware dropper, I will continue to reverse engineer its content to verify its intent. Second of all, you guys seem pretty smart. Why couldn't you find real jobs?

Storm on Blogger

http://sunbeltblog.blogspot.com/2007/08/storm-worm-hits-blogger.html

Don't believe anything I link to, ever. Even before this. :)