Stuxnet Memory Analysis and IOC creation
Written by Peter Silberman
The stuxnet malware has been making the press recently for two reasons. First it contains two drivers signed with a legitimate (at the time) cert. Second is it’s targeting SCADA systems. The malware is cool for a host of other geeky reasons. Nick Harbour, Stephen Davis, and I started looking at the malware Sunday afternoon. We had hoped to write a blog post about the specifics of the malware before we left for Vegas on Friday. However, in the short term I thought this malware would provide a great opportunity to demonstrate how memory analysis can be leveraged to find malware easily, and how the MANDIANT’s Indicator of Compromise editor (IOCe) tool can be used to describe the malware and what to look for.
The goal of every good IOC is to leverage the intelligence we have about the malware to find it effectively, while allowing for changes/ variants, and weeding out false positives. We can describe most aspects of malware using the IOC language, for this exercise we will focus our energy on writing a good memory IOC. In memory, malware appears rather naked and this is a prime example of that. When loaded, stuxnet spawns lsass.exe in a suspended state. The malware then maps in its own executable section and fixes up the CONTEXT to point to the newly mapped in section. This is a common task performed by malware and allows the malware to execute under the pretense of a known and trusted process. The first indicator in memory is the path it uses to spawn lsass.exe:
Notice that the path to lsass.exe has extra backslashes so when the backslashes are resolved by CreateProcessW the path is c:\windows\\system32\\lsass.exe instead of c:\windows\system32\lsass.exe. This is seen in the following screen shot taken from Audit Viewer:
Notice the arguments in each process. The process with a score of 100 is the original lsass spawned by the system. The process with a score of negative 145 is the lsass spawned by the malware. The arguments are very distinctive and a great indication that something is wrong. This is a fine IOC for this specific variant but fixing this and rendering the IOC useless is a trivial task for this malware author. So let’s keep building out the IOC.
If we examine the lsass process further we see another indicator that something is wrong.
Above is a complete DLL listing of the malicious lsass. Who can spot what is missing? If you noticed the lsass.exe itself is missing you are correct. The original lsass has about three times the number of DLL’s and also includes lsass.exe in the listing:
The listing continues but notice lsass.exe at the top. The lack of a binary and DLLs in the malicious lsass listing reconfirms what we already knew. That the malware used a process suspend and unmap technique. When the attacker unmaps the lsass.exe section, the lsass.exe is removed the VAD tree and subsequently doesn’t show up when doing a DLL listing based on VADs. Spotting suspend and unmap via taskmgr or other live response tools would be very difficult. In this case the malware author took extra care and created the process with the correct privileges allowing the attacker to mimic the correct lsass.exe user.
The next addition to the IOC is the digital signature itself. The drivers were signed and verified:
<DigitalSignature>
<SignatureExists>true</SignatureExists>
<SignatureVerified>true</SignatureVerified>
<Description>The file is signed and the signature was verified.</Description>
<CertificateSubject>Realtek Semiconductor Corp</CertificateSubject>
<CertificateIssuer>VeriSign Class 3 Code Signing 2004 CA</CertificateIssuer>
</DigitalSignature>
We can use the fact that this certificate has now been revoked and add this to our IOC. This again is not a great variant resistant IOC because the attacker can sign their driver with a new cert, if they have one, or have an unsigned driver. In either case those changes will render this IOC useless. We will still add it to our existing IOC knowledge base.
The next behavior to create an IOC for is the injection component. Stuxnet injects at least one binary into svchost, lsass, services and we see references for the potential to infect winlogon as well. Stuxnet is actually injecting a full binary not just shellcode into these processes.
When we examine the inject sections we see the binaries import three dlls:
The most abstract way to write an IOC for this is to say any process that has an injected binary that imports ADVAPI32.dll or KERNEL32.dll or USER32.dll flag as part of the stuxnet malware family. There is a chance we could end up flagging other things as part of stuxnet but adding imports makes the IOC a little too strict. This is a much better signature the previous two. It allows for some modification and requires the author to actually make more than one line code changes in their malware to force us to miss it. Now it’s still feasible that the malware could be modified and we could miss it with the current three IOC’s we have so let’s continue building our IOC. The final thing to create an IOC for is the rootkit component. The rootkit component is designed to hide the presence of the malware and LNK file on the filesystem. To do this they use an old standard technique that AV and rootkits have been using for years. The rootkit layers itself on filesystem devices, if you are running on VMWare it will layers itself on the VMWare filesystem driver. If we create an IOC describing the driver layering we can make it very hard to defeat detection. The IOC we create states that any driver that layers itself on sr.sys, fs_rec.sys, and fastfat.sys will be flagged. There is definitely a chance for false positive but it should be a small set of hosts and you can add parameters to exclude the false positives if need be. This IOC could be expanded if you are running truecrypt or other filesystem software the IOC might need to be updated or modified to include or exclude certain drivers. IOC’s can and should be tailored for the environment where necessary. The final memory IOC looks like this:
Lets translate this IOC into english. If a process with an argument that contains \\system32\\lsass.exe OR a driver exists that has a certificate subject that contains Realtek Semiconductor Corp flag it as stuxnet. OR a driver exists that has attached to the following fs_rec.sys AND sr.sys AND fastfat.sys flag the driver as part of stuxnet. OR a process has an injected section AND the injected section imports any of the following DLLs advapi32.dll OR kernel32.dll OR user32.dll. This is a pretty solid IOC for malware in memory as we do more work on the malware we may find more nuisances we can add to it, this is a good start.
Our focus here was to describe the malware in memory using an IOC. But when we write IOCs for the field or customers we take everything into account including disk, registry, filesystem, eventlog, etc. A more complete IOC for this malware looks like:
This IOC reads the following way if the file has a section named .stub OR a file exists named mdmcpq3.pnf OR a file exists named mdmeric3.pnf OR a file exists named oem6c.pnf OR a file exists named oem7a.pnf OR all of the following drivers are attached to by one drivers fs_rec.sys, sr.sys, fastfat.sys OR a process has an injected section AND it imports any of the following DLLs advapi32.dll, kernel32.dll, user32.dll OR a file exists named mrxcls.sys and it has a certificate subject of Realtek Semiconductor Corp OR a file exists and it has a name of mrxnet.sys and it has a certificate subject of Realtek Semiconductor Corp OR a registry key path exists of HKEY_LOCAL_MACHINE\SYSYTEM\ControlSet001\Services\MRxCLs\ImagePath AND has a value of mrxcls.sys OR a registry key path exists of HKEY_LOCAL_MACHINE\SYSYTEM\ControlSet001\Services\MRxNet\ImagePath AND has a value of mrxnet.sys.
Nick Harbour, Stephen Davis, Jamie Butler, Kris Harms and I will all be at Blackhat this year teaching classes ranging from Malware Analysis Crash Course, Advanced Malware Analysis, Advanced Memory Analysis in Incident Response, and Incident Response. Even if you don’t take a class, join us for the MANDIANT pre-game party from 7-9 on Wednesday before going out for the night!
Tags: IOC, IOCe, malware analysis, Memory analysis, Stuxnet
. 21 Jul 10 | General | Comments (0)
Fresh Prints of Mal-Ware: Choose Your Own Adventure!
Written by Christopher Glyer
Kyle Dempsey and I have been busy putting together content for the upcoming Fresh Prints webinar, “Choose Your Own Adventure,” being held this Thursday, April 15th at 2PM EDT. If you thought of the Choose Your Own Adventure® book series when you saw the title, you understand where we’re going with this.
This webinar’s content was developed based on feedback we received from registrants, specifically:
- How does MANDIANT “Find Evil”
- Malware internals
After gathering responses, what we found was that people know the basics about the APT – and what they are most interested in knowing is how our consultants go out in the field and actually find the attackers.
I have seen some presentations pop-up that speak at a high level on this threat, but they always stop short of showing you how the attackers compromise an organization’s network or how an investigation was conducted. Kyle and I wanted to create a webinar that showed how we actually conduct an investigation (tools used, screenshots of results…etc.) using real client data (used with their permission).
The webinar details what we would do with traditional drive based forensics to find malware and contrasts it with real examples of using an approach that scales to an enterprise environment with tens of thousands of hosts (without using an army of investigators and imaging every system under the sun).
I hope you can join us Thursday for the webinar. As always, there will be plenty of time at the end of the presentation for Q&A.
Tags: Advanced Persistent Threat, Fresh Prints of Mal-Ware, malware analysis, webinar
. 14 Apr 10 | General | Comments (0)
M-Trends: Advanced Persistent Threat Malware
Written by Wendi Rafferty
There are a lot of reports in the news about the types of malware being utilized by the Advanced Persistent Threat (APT) attackers. Our upcoming release of M-Trends will go into great detail about the types of malware, its capabilities, and how the attackers leverage a variety of malware throughout a breadth of victim organizations to accomplish very specific goals. Over the next week, the MANDIANT blog will feature excerpts from our upcoming M-Trends report that illustrate just how difficult it is to identify APT techniques.
The most significant commonality of APT malware is that it hides in plain sight. It avoids detection by using common network ports, process injection and Windows service persistence. Every piece of APT malware cataloged by MANDIANT initiated only outbound network connections. No sample listened for inbound connections. So, unless an enterprise network is specifically monitoring outbound network traffic for APT-related anomalies, it will not identify the APT malware outbound beaconing attempts.
A few of the most poignant stats about APT malware are listed below:
APT Malware:
- Average File Size: 121.85 KB
Most Common APT Filenames:
- svchost.exe (most common)
- iexplore.exe
- iprinp.dll
- wiinzf32.dll
APT Malware avoids anomaly detection through:
- Outbound HTTP connections
- Process injection
- Service persistence
APT Malware Communication:
- 100% of APT backdoors made only outbound connections
- 83% used TCP port 80 or 443
- 17% used another port
Because APT malware is so difficult to detect, simple malware signatures such as MD5 hashes, filenames, and traditional anti-virus methods usually yield a low rate of true positives. M-Trends will provide detailed information about how exactly organizations can posture themselves for success when fighting attackers with such specialized and sophisticated capabilities.
If you’d like to register for a copy of “M-Trends,” drop us a note at info(at)mandiant(dot)com otherwise, keep your eyes peeled to our blog and http://www.mandiant.com for the official release of “M-Trends.”
Special Thanks to Peter Silberman, the MANDIANT malware analysis team, and product engineers for their work in developing this information.
Tags: Advanced Persistent Threat, APT, M-Trends, malware analysis
. 15 Jan 10 | General | Comments (0)
Flex your Memory Forensic skills at CEIC!!!
Written by Peter Silberman
MANDIANT will be at this year’s Computer Enterprise Investigation Conference (CEIC). I will be there as well running a contest for incident responders. The contest is designed to test your ability to identify malware in memory. We have all heard of the Advanced Persistent Threat, we know the acronym APT. If you’re not familiar with APT or want to become more familiar check out https://cc.readytalk.com/cc/schedule/display.do?udc=1s8rbdxuuzuf7.
But how many of us have seen these cute cuddly creatures on live systems or in dead memory? This is your opportunity to come see if you can find the malware of an actual APT incident as well as some other incident of my own creation.
The contest will run two days and kick off Monday, May 18 at 9:45 a.m. The contest will work as follows: you will be given access to a virtual machine (VM). This VM will be pre-loaded with Audit Viewer and Memoryze. Audit Viewer will already have the audits needed to solve the incident loaded, which will cut down on the time needed at the station. You will have 10 minutes to go through the results of the audit and answer a set of four to five questions. At minutes 4, 6, and 8 you can ask for hints. If you answer three more of the questions on the first day you are eligible to compete on the second day. The second day will work the same. One of these two days will contain actual APT malware taken from an incident we responded too. The contest is designed to simulate what we see on a daily basis and to help attendees learn more about finding malware in memory. The prize will be an iLive IP908B 9″ Portable DVD Player With iPod® Dock And Swivel Screen.
If you are wondering how to prepare for the contest, we recommend you read the Audit Viewer user guide included in Audit Viewer. You should understand the data displayed by Audit Viewer and how to navigate/search Audit Viewer results. You will not have to run Memoryze as all the data you need to solve the case will be preloaded into Audit Viewer. We will have an Audit Viewer training slide deck running at the contest so you can if you’d like cram prior to the competition but as one of my college professors might have said “cramming is not recommended.”
You may say, “well I don’t have much memory analysis experience.” That does not matter! Stop by the booth, I will be there to walk through how to do memory forensics on 15 or so unique memory images. Each memory image is a different type of malware or scenario. All our demonstrations will utilize MemScript, which is a FREE EnCase script written by Kelcey Tietjen that integrates memory analysis into EnCase. This is a great chance to come and learn something new. And, as always, if you have questions about previous talks we’ve given or upcoming research you’ve read about, I’ll be more than happy to chat about those as well. So stop by, watch others compete, come and see the big red box, talk memory, APT, fluffy bunnies and more.
Hope to see you there!
Tags: APT, Audit Viewer, Encase, malware analysis
. 11 May 09 | General | Comments (0)
Article on how to use Memoryze and Audit Viewer for malware analysis
Written by Peter Silberman
I know not everyone reads OpenRCE, but it has been a favorite haunt of mine since Pedram launched it. Over the holiday, I posted an article there about how to use Memoryze and Audit Viewer to do malware analysis since that has always been one of my hobbies.
See Memoryze Memory Forensics Tool at OpenRCE.
NOTE: John O. pointed out that having spaces in your path where Memoryze was installed may prevent Audit Viewer from launching Memoryze because of how batch scripts’ input is interpreted. If you install Memoryze in a path with no spaces you should be fine.
Thanks to Pedram for helping with the post to OpenRCE and to Danny Quist at Offensive Computing for his blog entry.
Tags: Audit Viewer, malware analysis, Memoryze, offensive computing, openrce
. 01 Dec 08 | General | Comments (0)
