When I spend time working solely on reverse engineering malware, I don’t often get the whole story with a malware sample. I wasn’t curious about the name fxsst.dll until we had a plump stack of malware samples in our library that all had this name and were completely unrelated to each other. A quick check with our incident responders confirmed that in my latest specimen the malware was operational and the persistence mechanism was not immediately apparent.  It gave me a flashback of ntshrui.dll from last year and I decided to investigate the issue.

If you try a quick Google search, you will find that fxsst.dll is a legitimate system DLL, specifically the fax server.  The DLL is found on most systems that were installed with default settings, though it is an optional feature during the operating system installation process.  It resides in the System32 folder, and a search for the DLL on a live system with Process Explorer shows that it is loaded inside the Explorer.exe process.  At this point it sounds very similar to the ntshrui.dll problem, but we’ll keep digging.

I found that my malware analysis VM did not contain fxsst.dll so I placed a malware DLL of this name in the System32 folder and rebooted. The malware was loaded by Explorer.exe upon reboot. Unlike ntshrui.dll though, there is no mention of fxsst.dll anywhere in the Registry. A string search through Explorer.exe reveals that it is also not loaded directly by the program through its import table or dynamically with LoadLibrary(). A complete search for fxsst.dll through all files revealed it to be referenced by the file stobject.dll in the System32 folder.

Stobject.dll is the System Tray component of the Windows Shell (the tray at the bottom right of your screen). It is loaded by Explorer.exe as an In-Process Server (InprocServer in Windows lingo) and utilized through a COM interface. It is referenced in the Registry as shown below.

With the mystery of stobject.dll solved, we can focus on how it loads fxsst.dll. We also need to figure out what a piece of malware must do to successfully replace the legitimate DLL and still ensure a stable system. The following is the decompiled fragment of stobject.dll which shows the loading of fxsst.dll.

According to this fragment of code if the fxsst.dll file is found it will be loaded and the two functions, IsFaxMessage() and FaxMonitorShutdown() will be resolved and stored in a pair of global function pointers. If the DLL is not found, or if the functions were not found within the DLL, then the global function pointers will be NULL. Let us now examine how these function pointers are used to see if a NULL pointer will adversely affect the program.

The IsFaxMessage() function is used only once, and in the fragment above you can see that the program checks to see if it is NULL before calling the function. If the pointer is NULL, then the program just skips this piece of functionality. The same is the case for FaxMonitorShutdown(). Why does this matter? If a malware replaces fxsst.dll and is loaded by Explorer through stobject.dll, then it doesn’t need to implement the fax server function calls. The only repercussion is that the system can no longer act as a fax server, but that is a feature I don’t think anyone would notice was missing. The malware authors obviously arrived at the same conclusion.

Since fxsst.dll resides in the System32 folder, is not protected by KnownDlls and is loaded by the Explorer.exe process, it is vulnerable to the same DLL load order hijack as ntshrui.dll. By that I mean you can place a malicious DLL in the C:\WINDOWS folder and it will load instead of the legitimate copy in System32. You can also just overwrite the copy in System32 and the user of the system will not notice. Unlike with ntshrui.dll, the malware replacing fxsst.dll doesn’t really need to take the extra step of loading the legitimate copy to restore its important functionality.  In this case, the original functionality is useless to all but the last few people in the world who still use their Windows computer to receive faxes.

Conclusion (and TL;DR version):

You can take pretty much any malware DLL, name it fxsst.dll and drop it in C:\WINDOWS or the System32 folder and Explorer.exe will load it at boot time. No hassle, no fuss. There are bound to be more problematic DLL locations like this, but I’ll keep spreading the word as we find them.

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!

• 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.

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.

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!