Review: SANS FOR610 Reverse Engineering Malware

| August 3, 2010

sans_logo.gifReview by Justin Kallhoff, CISSP, C|EH, GPCI, GCIH et al 

Current statistical evidence from multiple reputable sources suggests current signature-based anti-malware technologies have detection rates below 35%. I don’t think any of us expect that percentage to increase, instead I expect it continue to decrease as malware authors continue to learn, cooperate, and gain sophistication. This disturbing trend has information security paranoids, like me, continually evangelizing “it’s not a matter of if, it’s a matter of when” your organization will experience a compromise.

Those of us responsible for protecting organizations from malware or responding when defenses fail need to elevate our reverse engineering and forensics skills for the rocky road that lies ahead. I have been frustrated a number of times while attempting to determine what a particular piece of malware did to a system. A majority of organizations lack defense-in-depth and appropriate logging levels, so it can be very difficult to determine who did what, when, and what may or may not have changed as a result. In many situations, a post-mortem analysis or a reenactment may be required to determine the extent of the incident. This is where Lenny Zeltser’s SANS Forensics 610: Reverse Engineering Malware course comes in handy. It is now a 5-day, in-depth course covering a multitude of topics involving malware analysis.  

Active Image
Active Image

Discuss in Forums {mos_smf_discuss:/root}

vlive_logo_130.jpgFree iPad 2! 

From now through June 22, 2011, SANS will send you a free 16GB iPad 2 with Wi-Fi when you register and pay for one of the following vLive! courses:

FOR610: Reverse-Engineering Malware: Malware Analysis Tools and Techniques
Learn how to assess and reverse-engineer malicious software with Lenny Zeltser and Michael Murr.  Course starts July 25 and meets Mon./Thu. evenings.
MGT414: SANS® +S™ Training Program for the CISSP® Certification Exam
Study the CISSP®’s 10 Domains and prepare to pass the exam with Ted Demopoulos.  Course starts July 25 and meets Mon./Wed .evenings.

FOR408: Computer Forensic Investigations – Windows In-Depth
Learn the fundamental steps of computer forensic methodology with Michael Murr.  Course starts August 23 and meets Tue./Thu. evenings.

*NEW COURSE* SEC660: Adv. Penetration Testing, Exploits, and Ethical Hacking
Model and analyze the most prominent and powerful attack vectors with Stephen Sims, Bryce Galbraith, and Joshua Wright.  Course starts August 30 and meets Tue./Thu. evenings.

Use Promo Codes 05EH_iPad2BLK (Black iPad) or 05EH_iPad2WHT (White iPad)

Lenny has an impressive background including:

• MBA degree from MIT Sloan
• One of 22 GIAC Security Experts (GSE) in the world
• Co-Author of several books
• Incident Handler for the Internet Storm Center (ISC)
• Board of Directors member at SANS Technology Institute (STI)

Obviously Lenny is a smart and talented guy who knows a thing or two about malware.  To put it simply, Lenny seems to read assembly code like its kindergarten-level English.

Editor’s Note: For more on the courseware author and instructor himself, be sure to read the EH-Net Exclusive, Interview: Lenny Zeltser of Savvis and SANS Institute.

Day 1: Ringtones, Police, and Fundamentals

I attended FOR 610 in Baltimore, Maryland at SANSFIRE 2010.  As expected on the first day of any SANS course, a couple of people forgot to put their mobile phones on vibrate, so we all got to enjoy a few ringtones generating a few chuckles and one red face.

Not long after everyone was able to figure out their vibrate function, another funny, though more rare, SANS event happened; the sound of the Baltimore police department showing off their sirens.  I’ll admit, being somewhat aware of Baltimore’s crime statistics, I thought to myself, “This could be an hourly event.”  However, I’m happy to report, the sirens turned out to be an isolated incident.

Lenny’s first objective was to bring attendees from various backgrounds up-to-speed on the basic fundamentals required to understand the material being presented in the course.  This preparation included setting up a properly functioning virtual lab in order to analyze malware effectively and efficiently.  Some probably see this somewhat tedious task as a waste of valuable class time, but for me, knowing how to set up my own reversing lab with the appropriate tools was not only valuable, but something I could take back to my organization and gain value from immediately.

Having a well configured and isolated virtualized lab provides a number of advantages as it pertains to malware analysis including but not limited to:

• Snapshots enabling the analyst to reset the operating system to a point in time or running a scenario over and over to learn what happens.
• Running multiple operating systems concurrently on one system.  For the sake of this course, we created one Windows XP host and one Ubuntu (Linux) host.  The Linux host was provided by Lenny and was ready to rock with the tools required for the course.
• Granular control over what services are available to the infected system.
• Traffic analysis between various hosts on the lab network.
• Being able to utilize a single keyboard and mouse and clipboard sharing.

Behavior Analysis: Let it Rip and Watch What Happens

During the first morning we walked through the course outline and the lab setup.   Lenny provided an example and demonstrated the key techniques for malware analysis.  After getting everyone on the same page, we returned from lunch and dove right into executing our first piece of malware.  I realize that I’m a security nerd, but for me, having the freedom to double-click a known malicious file and knowing that I’m doing so in an isolated lab environment, provides me with some geek satisfaction.  I’m not sure why, but I get a devilish smile and my eyes open wide when I can watch malicious code do its thing right in front of me.  Processes starting, TCP ports listening, files appearing and disappearing, registry entries changing a mile a minute, what can I say, it just gets my security blood pumping.

The first malware specimen performed a number of interesting actions:

• Generated a new process
• Attempted to read a non-existent and uncommon .ini file
• Created a persistent start-up mechanism for itself via the common registry key for Microsoft
• Started listening on TCP port 113 (typically associated Unix Ident service)
• Attempted a DNS query for a particular hostname
• Attempted to connect to an IRC server

A lot going on already for our first analysis, but I was totally zoned in at this point and it was still the first hour of the course.  During this first analysis, I was learning a lot quickly, but I also got in a few laughs along the way. 

Malware authors, as it turns out have a few things in common with HBO comedians.  They both aren’t afraid to use four letter words, and they also both possess a sense of humor that many of us can easily relate to.  It’s an odd personality trait that seems to be prevalent in the security community, whether on the good or bad side of things; we tend to be funny and not afraid of using strong language to get our point across.
I personally appreciated Lenny’s choice to not use special characters, blurring, or any sort of obfuscation to hide the profane language.  After all, if you’re in the business of working with criminals or analyzing “less than moral” pieces of code, you should not be easily offended by profanity or you’re in the wrong business. 
Through further analysis of this Trojan, we learned even more useful information about its behavior.  The approach taught in this section of the course was to systematically give the malware the services it desires (yes, I just humanized malware) in a controlled environment.  I particularly appreciated this exercise and while I had tried some similar approaches previously, I was missing several key tools and lacked the experience required to do this analysis in a step by step, easy to understand process.

Code Analysis: Getting Dirty

While executing malicious code to determine what has changed on the system is a quick method for analyzing malware, a more comprehensive approach is to analyze the code methodically.  For those with a short attention span like me, this can be painstaking.  For those that really like to look under the hood aka “gettin’ dirty” to understand exactly how everything fits together, this may be right up your alley.
During the second half of day one, we started interacting with the debugging tools and understanding the basics of assembly code.  In hindsight, I wish I would have focused my attention better during these early stages of code analysis instruction.  I was unaware at that point how much of an important role understanding these pieces would be in subsequent days’ course material.

Unfortunately, like so many other SANS attendees, I had an unexpected event at my company which distracted my focus for a period of time.  On the bright side, the event ironically related directly to what I was at SANS to learn more about.

Day 2: Patching, Packing, and Spreading the Honey

Patching malware, what the heck does that mean?  I thought we were supposed to patch stuff to defend against malware?  According to Zeltser, “Patching malware refers to modifying malicious code to alter its functionality.”  In the course, the modifications were focused on bypassing authentication mechanisms of backdoor programs to make analyzing them easier.

Packing: The Game Increases in Complexity

Malware authors prefer that their masterpieces go undetected and complete their mission without hiccup.  However, in a scenario when the opposition discovers their presence, the authors want the analysis to either be too complicated for a sane person to complete or convoluted enough to send the investigator off on a wild goose chase.  Enter the process of packing, whereby the author compresses or encrypts the malicious executable.

As mentioned in the behavioral analysis section, sometimes providing the malware with the services it desires can provide some solid insight as to what the malware is designed to accomplish.  Honeyd (a lightweight honeypot) can provide a mechanism for an analyst to generate dynamic hosts (IPs) and services simulating the wild, wild Internet in your lab.

Browser-Based Attacks: You’re An Idiot


As the above screenshot illustrates, malware authors keep their sense of humor across attack vectors.  This particular JavaScript attack is more annoying than harmful, but generated a pretty good chuckle from me and a few other classmates when it appeared on the giant projector in class.  The attack includes some nice artwork and apparently a nice background jingle to sooth the anger you experience every time you close one browser window and another window opens up.  This process will eventually result in the victim rebooting their machine.  Granted this is a simple, old-school example in what has become a much larger problem.

Before reading the next line, consider two things: 1) the title of this section and 2) prepare yourself for a reboot, aka save any open work before proceeding.

If you’re one of those people that like to see things for yourself in action, click here. Smile

The threat landscape today is full of attacks that utilize the browser in some fashion.  I’ve read statistics from multiple reputable sources that suggest upward of 95% of attacks are client-side now.  Of those, I would hypothesize that a majority utilize the victim’s browser. But wait!  What about e-mail attacks?  The bad guys know that a majority of email systems block a lot of attachments, particularly executable content (we’ll ignore Adobe attacks for the purposes of this review).  So what do they do?  They send a hyperlink, because how many organizations block users from downloading anything via HTTP? Usually people respond to that question with, “Well we have an anti-virus solution in place.”  Two words or more like Office Space slang, Ummmmm Yaaaaaa.

Lenny’s course analyzes several browser-based attacks including the JavaScript example from above, Java Applets, ActiveX, Flash-based malware, and more.  We were introduced to tools for automating analysis and understanding some of the obfuscation techniques utilized.   As the threat landscape continues to focus on the browser and the client-side vector, understanding browser-based malware will become more critical for information security professionals.

Day 3: Assembly Code, Separating the Puppies from the Dogs

There isn’t a lot that can be funny or easy about learning and understanding assembly code, at least not for me.  I come from a SysAdmin background, so unfortunately I struggle with code analysis.  SANS610 states that one of the goals for the Day 3 courseware is to become comfortable reading code, not necessarily to become a coder.

The day’s material begins with a brief introduction covering terminology and fundamentals.  Some examples include: Compilers, functions, system calls, address space, variables, jumps, loops, and pointers.  The instruction is focused to assembly as it pertains to malware.  Lenny provides specific examples of how malware utilizes these concepts.  For example, loops could be used to encrypt/decrypt network traffic, perform a port scan, log keystrokes, etc.

The approach of defining technical terms or concepts and then giving specific examples of how things apply to the real world is a staple of SANS courses in my opinion.  It helps humans retain the information and be able to apply it in their own work.  Combining the lecture approach with hands-on labs throughout every course is a proven method.

The second half of day 3 takes a dive into common malware characteristics at the assembly level, focused on recognizing common patterns by examining the use of Windows API calls.  The breakdown of rootkits and DLL injection was nicely illustrated and explained by Lenny.

Keyloggers and Sniffers: Collecting the Jewels

Defacing websites and generating “you’re an idiot” pop-ups may still be around, but those aren’t the problems keeping information security professionals up at night.  The attacks that generate stress for security professionals today are about information, money and power.

The following statistics from the February 2010 Nilsen Report are staggering:

• In the U.S. alone, there are over 1 billion credit/debit cards in circulation (With a 2009 estimated U.S. population of 305 million, that’s about 3.5 cards per citizen regardless of age).
• There were 20.2 billion credit card purchases in 2009.

That’s what I call a lot of low hanging fruit.  There are 20 billion opportunities for nefarious entities to capture credit card holder data.  There are 1 billion different accounts to steal from.  Those statistics remind me of a popular analogy, “It’s like shooting fish in a barrel.”

A popular way for attackers to target banking credentials and credit card data is to install keystroke loggers or sniffers as part of their bots and worms.  In the course we investigated specific examples of keyloggers and sniffers.  The focus was to highlight what to look for and common malicious implementations.

It doesn’t matter if you’re in a consulting role or you work for an organization that relies on you to do incident response.  One of the most common questions to be answered is, “Were credentials stolen and what data was at risk as a result of the incident.”  Determining if a keylogger or sniffer dimension is present in the malware is a pivotal piece of information to obtain for a victim organization.

I hope that Lenny expands on this area of the course.  I’d like to see more time spent watching and analyzing keyloggers and sniffers in action.  I’d like to learn more about the methods malware uses to send data “back home” after collecting it.  I realize it’s difficult to pack as much content and learning into 5 days as Lenny does with 610, but I believe this element will become more the default, not the exception, if it hasn’t already.  As an analyst I feel like I need to be able to answer, with confidence, whether keyloggers or sniffers exist in an incident.

Day 4: Defensive Strategies of Malware

Malware authors continue to evolve and gain sophistication, typically ahead of the most current “Whiz Bang Product X.”  As part of that evolution malware authors continue to develop new ways of obfuscating their product through compression and encryption methods.  Ultimately the more time consuming, annoying, confusing, complex, and frustrating the malware author can make it for analysts, the better.

Day 4 starts with identifying packers.  Without knowing how to unpack a piece of malware, which requires you to know which packer was utilized, you’re pretty much out of luck.  Any malware written today with intentions to hit the masses will most likely utilize some sort of packer.

From there, several defensive techniques for preventing or hindering analysis were covered.  Examples include malware that deletes itself from the file system, fake error messages and VMware detection.

A few things to remember about attackers; they know our processes, they use the same tools, and they have access to the same technologies.  They don’t want to be detected or caught, they don’t want to go to jail, nor have their toys taken away.  The good news is many, definitely not all, of them are just as lazy as we are and they assume (correctly) the masses are mostly clueless about information security and malware.  The only option we have is to educate ourselves and gain experience.

Day 5: Shellcode, Document Files, and Memory Forensics

The first order of business for day 5 was to answer what the hell is shellcode?

Lenny states, “Shellcode is a sequence of bytes that represent assembly instructions.  These bytes correspond to opcodes that a CPU can execute and are often represented using their hexadecimal values.  Shellcode is an essential part of many exploits that we might identify when examining a malicious executable or document file.

Historically, shellcode has been used to spawn a shell on the exploited system.  However, shellcode is not limited to launching a shell; it is capable of executing any code on the system that is vulnerable to attack.”

Office and Adobe PDF p0wnage

I personally love this topic because pretty much the whole world is vulnerable to it.  As my friends at Qualys statistically illustrate at

Top 10 Internal Vulnerabilities: July 2010

1. Adobe Flash Player Multiple Vulnerabilities
2. Adobe Flash Player Update Available to Address Security Vulnerabilities
3. Adobe Acrobat and Adobe Reader Multiple Vulnerabilities
4. Adobe Reader JavaScript Methods Memory Corruption Vulnerability
5. Sun Java Multiple Vulnerabilities
6. Microsoft Office PowerPoint Could Allow Remote Code Execution
7. Microsoft Excel Remote Code Execution Vulnerability
8. Sev4 Microsoft Word Multiple Remote Code Execution Vulnerabilities
9. WordPad and Office Text Converters Remote Code Execution Vulnerability
10. Vulnerabilities in Microsoft DirectShow Could Allow Remote Code Execution

We penetration testers love this statistical data, but unfortunately malware authors are also very aware of it.  Enter SANS Forensics 610 needing to help the good guys understand how to analyze malicious Office and Adobe files.  Lenny’s course introduces us to several tools that help us analyze office files.  These tools assist in everything from quickly isolating macros to actually flagging files as malicious.

When it comes to PDF documents there are some exploit and vulnerability differences compared to Office, however the problem is just as widespread and difficult to defend against.  Lenny mentions, “Besides using normal JavaScript obfuscation, JavaScript embedded in a PDF file can reference other objects in the PDF document to extract data from.  This can make analysis of such documents very difficult.  Even anti-virus vendors have a hard time reliably detecting malicious PDF documents.”  Funny, I thought it was because most anti-virus vendors’ approach to defending against malware is fundamentally flawed.

Lenny points out a cool, yet very vulnerable part of PDFs, is their support for dynamic actions including:

• Sounds and movies
• Launch a command upon opening
• Connect to a URI
• Execute JavaScript
• Flash and HTML support

SANS Forensics 610 was my first exposure to malicious PDF analysis tools and frameworks.  I think it’s pretty cool, cutting-edge stuff for a massive problem.  This information gives analysts some help in figuring out what happened when a client or a boss calls and says, “Cyndi from HR opened a suspicious PDF attachment and now her computer is acting really weird.”

Memory Forensics

The first step that a majority of people take when they detect a potential compromise on a machine is to reboot.  The more paranoid/aggressive IT admin may just unplug the power to the host.   There is a plethora of useful information that forensics professionals can obtain from the memory of an infected machine, including:

• Process information
• Network connections
• Logged in users
• Open files
• Passwords
• Encryption Keys
• Unpacked/Decrypted executables
• Registry Hives
• File/Web page artifacts

The challenge is obtaining the memory from the machine before it is rebooted or powered off.  However, Lenny points out in the course all is not lost if you’re analyzing a machine post reboot or power off.  Memory forensics could easily be a multi-day course on its own, so don’t expect to be a memory forensics expert after this course.

This section walks through memory acquisition and the tools and techniques utilized in memory analysis as it pertains to malware.  One of those tools is the Volatility Framework, a free collection of memory forensics tools.  There are several hands-on exercises focused on analyzing the memory of malicious code using the framework.


Malware is evil; analysis can be fun and is not necessarily rocket science.  SANS 610, Reverse Engineering Malware teaches a systematic approach to analyzing malicious code utilizing the latest and greatest tools and techniques.  It’s not earth shattering news that the prevalence of malicious code will continue to increase for the foreseeable future.  The knowledge and skills this course provides will enable those responsible for responding to and preventing incidents to better understand and respond to emerging malware threats.

Twitter: Infogressive

Justin Kallhoff is the CEO and Founder of Infogressive, Inc., headquartered in Lincoln, Nebraska.  Infogressive is a security-centric information technology consulting firm.  His focus as CEO is growth, his commitment in the office and in the field are the vital and nurturing forces fueling Infogressive’s success. Mr. Kallhoff earned his Bachelor of Science in Biopsychology from the University of Nebraska.  He worked for Alltel in a variety of technology roles including data engineering for six years.  He also worked for Information Technology, Inc., a division of Fiserv, where he worked with financial institutions from around the country.  Prior to founding Infogressive in Nebraska, Justin was a security consultant in the Chicago area. In his free time, Justin is a member of the SANS GIAC Advisory Board, the FBI’s Infragard program, and the Lincoln Young Professionals Group.  He is an avid sports fan, absolutely loves to travel, enjoys cooking, and attends as many “geek conferences” as possible.

Category: /root

Comments are closed.