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!

The persistence technique I’ll describe here is special in that it doesn’t leave an easy forensic trail behind.  A malware DLL can be made persistent on a Windows host by simply residing in a specific directory with a specific name, with no trace evidence in the registry or startup folder and no modified system binaries.   There isn’t just one directory location and DLL filename that are candidate locations for this persistence mechanism but rather a whole class of candidate locations exist for any given system.  On my laptop (Windows 7 64-bit) there are no less than 1032 such path and DLL name combinations where a DLL could be placed such that it would automatically be loaded at some point during my normal boot-up, and that’s just for a 32-bit DLL!  If you had a 64-bit malware DLL the number would be much higher as I have many more 64-bit processes running at boot time.  So how does this work?

DLL Search Order Hijacking

When an application requests to load a DLL either statically via an import table in its executable file, or dynamically via the LoadLibrary() function the operating system will look for the DLL in a predefined sequence of locations.  This sequence is defined in the MSDN documentation here: http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx.  The most important tidbit of information to take away from that document is that the first place the application looks for a DLL is the location of the executable itself.  This isn’t always the case though.  If the DLL name that is requested is listed in the “\\.\KnownDlls” object then it will always load from a fixed location (the System32 folder).  This object is populated at boot-time using data from the Registry at the following location:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\KnownDLLs

Microsoft employee Larry Osterman describes this in a blog post (http://blogs.msdn.com/b/larryosterman/archive/2004/07/19/187752.aspx).  He states in the post that the KnownDlls object will be larger in memory than what is in the Registry key and will be built recursively from the statically imported DLLs from any DLL listed in the registry.  In the limited testing I’ve done on Windows XP and Windows 7 systems, the KnownDlls object in memory is identical to the list provided by the KnownDLLs registry key.

Casual browsing of the KnownDlls key will reveal a short list of about 30-35 of the most commonly used DLLs.  For example, the low level networking API DLL “ws2_32.dll” is contained in this list.  Whenever any application attempts to load a DLL named “ws2_32.dll” it will always load it from the System32 folder because it is listed in this key, regardless of where the application was launched from.  The KnownDlls system provides a thin layer of security for this small set of crticial DLLs because an attacker can’t simply place a DLL named “ws2_32.dll” inside a folder containing an application which uses ws2_32.dll and expect their local copy to be loaded.  The KnownDlls system is far too limited to provide any realistic sense of DLL loading security though.  For example, even though we can guarantee that the copy of ws2_32.dll that will be loaded will always be the one from system32, other components loaded when ws2_32.dll is loaded (such as iphlpapi.dll and mswsock.dll) are not guaranteed because they are not covered by KnownDlls.

Lets imagine that we had a legitimate program called update.exe which ran from the location “C:\Program Files\MyCompany” and loaded ws2_32.dll, all we would have to do to make update.exe load our malware DLL is place our malware in the “C:\Program Files\MyCompany” directory and give it the name “iphlpapi.dll”.  When the update.exe program runs it loads ws2_32.dll, which in turn loads iphlpapi.dll which it loads from the application directory first before checking the System32 folder where it legitimately resides.  All the malware author needs to do is make sure their malicious iphlpapi.dll eventually loads the real thing and the user of the system (and a forensic analyst most likely) will have no idea that malware has been loaded.

Real-World Usage

You might have come to the conclusion in reading the description of the problem above that executables which reside in the System32 folder are not susceptible.  If you thought that, you’d be correct.  If you also thought that there is no real practical problem because all consistent and reliably placed startup binaries exist in the System32 folder, you’d be incorrect.  Case-in-point: Explorer.exe .  Strangely, this binary resides in C:\Windows (I assume for historic reasons).  So when explorer.exe launches and it requests a DLL that is not protected by KnownDlls, the first place the system looks to find the DLL is the C:\Windows directory.  Thus far, the most common place we’ve found this malware persistence technique being used is in the location and name “C:\Windows\ntshrui.dll”.  The real ntshrui.dll is located in the System32 folder but since this dll is loaded by Explorer.exe and not protected by KnownDlls, it’s unfortunately susceptible to DLL search order hijacking.

The Extent of the Problem

Once you really understand the nature of the problem it may occur to you that it’s a very widespread and pervasive issue.  It has always existed in Windows and will likely exist for the foreseeable future.  To alter the DLL search path mechanism could have severe backward-compatibility problems for Windows and is most likely not going to happen due to the high value they have always placed in compatibility (We love you Raymond Chen!).  I’ve written a program to identify all locations and filenames that a DLL could be placed to achieve persistence on a given system.  The idea is that you can run this program on a clean (Gold Image) system and forensically search for any DLL name listed in the output on a machine you suspect of being compromised with this method of persistence.  Similar programs may be developed to attempt to identify hijacked DLLs on a live system.  I chose to write this program first however because its output helps to explain the extent of the problem.  I ran the program on my laptop and it produced output which contained 1032 lines, each describing a location and filename that a DLL could be placed to be loaded at boot-time by my system.  On a clean XP SP2 machine I get 91 locations listed.  Here are a few lines from the output from my laptop:

Hijackable Location: C:\Program Files (x86)\iTunes\SspiCli.dll

Hijackable Location: C:\Program Files (x86)\iTunes\CRYPTBASE.dll

Hijackable Location: C:\Program Files (x86)\iTunes\CoreFoundation.dll

Hijackable Location: C:\Program Files (x86)\iTunes\MSVCR80.dll

According to this output, some program that loads when my system boots (most likely iTunes) attempts to load the DLL named “CRYPTBASE.DLL” which is commonly found in the System32 folder but an attacker could place a malicious DLL in the iTunes folder and that would be loaded instead.  The program examines running processes and determines hijackable DLL locations by the following properties (applied to each loaded dll in every running process in the system):

1. The process executable that loaded the DLL is not located in the System32 folder
2. The DLL name is not found in the KnownDlls object
3. The DLL is not found in the same directory as the executable

Any loaded DLL that contains all three properties is susceptible to being trumped by search order hijacking.

The tool (compiled and source) to identify possibly malicious 32-bit DLL locations from a clean system can be found here.

Many of you probably already know Christopher.  He’s delivered two separate webinars, including a previous State of the Hack titled “Silent But Deadly” and “Fresh Prints: Choose Your Own Adventure.”  These webinars gave you more information about the Advanced Persistent Threat (APT) and provided a detailed look into the malware used by this attacker.  However, one area that we haven’t discussed is how to remediate the APT once detected.

As a result, we have assembled a team of incident responders to create a list of the most common and generally applicable remediation strategies we’ve developed over the past year.  These remediation strategies build on our previous webinars and M-Trends report to provide guidance on how to protect against phishing attacks, limit lateral movement, disrupt C2 communications and facilitate investigation of future attacks.  If you haven’t had the opportunity to listen to our previous webinars and read the M-Trends report, I’d encourage you to do so as it will provide some additional background to Thursday’s webinar.  You can find the listing of previous webinars on our website under the News & Events section. To request a copy of M-Trends, simply click here.

Together, Christopher and I will draw on our experience as consultants over the last 10 years to discuss common problems we consistently see at client sites. We will offer remediation solutions, define associated implementation challenges, and discuss a few case studies where we’ve witnessed clients successfully execute our recommendations.  Although we’ll only be providing a subset of the hundreds of recommendations we’ve made, Christopher and I will be more than happy to field specific questions related to your environment.

I hope you can join us for the webinar this Thursday.  There will be plenty of good recommendations, excellent discussion, and a picture of me in jail.

For more information, and to register, click here.

Now, I know 256 TB is not going to be typical, but acquiring even 4 GB to 12 GB of paging files can take a long time. The pagefiles are in use and locked by the operating system. To gain access, tools typically parse the filesystem for access to the sectors that represent the pagefiles. This prolongs the time required to acquire the files.
 
Next time in this series, we will discuss more about time and its implication on the paging files. If this series is boring you, the memory forensics class at Black Hat contains more hands-on applications and use cases. This year, Aaron LeMasters, author of Web Historian 2.0, will be helping with the class. I hope to see you there.

• Collects web history, cookie history, file download history, and form history into data sets
• Simple/powerful UI based on tabbed organization of datasets
• Perform a live artifact scan of the local system
• Perform an artifact scan of one or more arbitrary history files from all supported browsers
• Import results from existing XML scan documents
• Data displayed in gridview style with full search, sort, and filter capabilities
• Custom filters can be created and applied to one or more data sets
• Export data sets to XML, HTML or CSV
• Extract and export history files used in live artifact scan
• Quick copy/paste selected gridview rows to clipboard
• Customizable scan settings can tweak the scan to target specific browsers and data sets
• Right-click context menu for narrowing gridview data instantly
• Select which columns to display in each dataset
• View page thumbnails and indexed content
• Export sanitized version of history results to distribute to others
• Website Analyzer provides visualization of datasets using bar graphs, pie charts and timelines
• Website Profiler shows a quick “report card” of artifacts for various websites

The custom filters mentioned above are extremely useful for narrowing the scope of your web history investigation. Web Historian ships with several pre-defined filters that allow you to quickly cull through large web history data sets.  For example, you can instantly filter the web history data by visit type to only show hidden page views caused by ads; or, filter the file download history data to only show downloaded media (movies, images, etc.), PDF’s, or plain text files.  You can easily create your own filters using the filter editor and configure Web Historian to automatically save any of your searches as filters.  Finally, more filters are accessible with a simple right-click on any web history item.

Also new in Web Historian 2.0 are the Website Analyzer and Website Profiler features.  The Website Analyzer allows you to visualize web history data (rather than scrolling through pages of records) and generate useful bar graphs, pie charts and timeline plots that can be used in an external report.  The Website Profiler generates a quick “report card” summary of any domain in your web history data, showing all artifacts created on your system when it was visited (page titles, cookies, cached files, form data, etc).  This feature allows you to get a quick impression of how a site behaves.  The screenshot below shows the profile of CNN.com:

We hope you enjoy the new features in this release of Web Historian.  As usual, if you have any questions, comments or feedback, please head on over to the user forum.

Stay tuned for even more exciting features coming soon!  If you would like a demo or talk to me about features, I will be at Blackhat USA in Las Vegas this summer and hope to be accepted to demo Web Historian 2.0 at Blackhat Arsenal.  And finally, don’t miss out on our memory forensics training at Blackhat:  Advanced Memory Forensics in Incident Response.

Download Web Historian 2.0

Kris Harms and I will present the next State of the Hack webinar in front of a live audience at the MANDIANT booth (#5), on Wednesday, June 16, from 12:30-1:30PM EDT. And for this webinar only, we’ll be taking live questions from the floor. Of course, you can also ask questions on the webinar chat channel if you’re not in Miami with us.

As usual, we’ll also cover a few case studies. We’re going to focus on cases that started out as one thing, but turned out to be something completely different. In the words of VP Steve, “It’s like we went to see a fight, and a hockey game broke out.”

There will be more time than usual for Q&A, by webinar chat and live from the exhibitor hall. If you plan to attend the conference, stop by our booth before and during the broadcast. We’ll try to take your questions live on the air – about the case studies, or about other interesting topics. Can’t make the conference? Don’t worry, you can still register and ask questions beforehand using the registration form.

Learn more and register here.

So what is included in Memoryze and Audit Viewer 1.4? Well, here is the short of it.
 

Memoryze:

• Support for Windows 2003 x64 SP2
• Improved support of Vista SP1 and SP2 including port enumeration and a better installer
• Enumeration of digital signatures for all loaded modules in a processes’ address space, hooked and hooking drivers, and all drivers found by driver signature scans
• Enumeration of MD5/SHA1/SHA256 hash on disk for all loaded modules in a process’ address space and all drivers found by driver signature scans
• Updated documentation
• Single installer for 64-bit and 32-bit versions

 
Audit Viewer:

• Improvements to the Malware Rating Index (MRI)
•      Report visualization of MRI results
•      MRI rule editors that will allow users to graphically edit the MRI rule file
•      Handle Trust view to help identify suspicious handles
• Ability to search results within a specific process
• Multi-select with copy
• Multi-select and export to a CSV file

 
Those who attended the CanSecWest Training in March have already been enjoying many of these features in beta form for months, and we are committed to ensuring that those who attend the Advanced Memory Forensics in Incident Response class at Black Hat will get early access to the next version of Memorzye, which will support Windows 7 64-bit.
 
As for the Black Hat training, there is a lot of new and updated content for 2010.

• Coverage of 64-bit operating systems
• New section on malware covering different malware techniques and how they stand out in memory
• Four new case studies ranging from real Advanced Persistent Threat (APT) incidents, to spear phishing attacks, and everything in between
• Student receive early access Memoryze and Audit Viewer for Windows 7 64-bit
• Students receive the only free tool to analyze Windows Vista
• Students receive the only free tool to analyze Windows 2003 64-bit
• Better data collection to help identify processes and drivers as malicious or not
• Added the Malware Rating Index (MRI), which helps automatically identify many malware behaviors discussed in the class. Through a simple user interface, students learn how to write rules to identify malware in their own work environments. MRI then uses those rules to score processes as suspicious or not.

 
I would like to thank James Long who pointed out an issue with the batch scripts* and Peter Villadsen who worked so hard to improve the build process and installation for Memoryze. Peter and I would also like to thank all our loyal users. We appreciate all your feedback, and we hope to see you in Las Vegas.

 
* When specifying an output directory from the command line with the batch scripts in Memoryze, the directory must already exist.

As part of the Digital Analysis Lab track at CEIC, MANDIANT Director Rob Lee will be teaching Super Timeline Analysis. You will learn how to establish a single framework from which you can analyze multiple examinations of time based data in this hands-on practical.

Move over Iron Man – MIR 1.4 is coming!

We wanted to let the dust settle from the other release of superior red metal before we announced ours!

MANDIANT is releasing the next version of MANDIANT Intelligent Response at CEIC 2010.

Here are just some of the features MIR 1.4 includes:

• Support for the OpenIOC open indicator format – a free-to-use, open XML schema for describing indicators of compromise.
• Agent support for Windows 7, 64-bit systems for non-memory forensic audits.
• Agent support for Windows Vista 32-bit systems.
• Agent support for 64-bit memory forensic audits for Windows 2k3 systems.
• Optional Agent installation into “self-hiding” mode.

So what else has changed since MIR 1.3?

Come visit us at CEIC booth 706 and find out!

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

• Do mass malware families share enough common attributes across families? Example, does conficker share code with waledac? If so, is it enough so that we could consider them members of a sub family. Also maybe proving they were written by the same author(s) or group of authors.
• Do mass malware families share code amongst APT samples? Example, this could mean that we find samples of subseven that match some of our APT backdoors (again just an example).

 
These two questions alone are very interesting because the results could indicate some author of a mass malware sample is also authoring malware for targeted attacks.
 
But we didn’t stop there. We also wondered:

• Do rootkits from rootkit.com have very high similarities to rootkits found by MANDIANT and out in the wild?
• Do APT samples of family A share enough in common to be also classified as part of family B? We can draw a lot of interesting conclusions if this is the case.

 
These are all interesting questions, but we had a lot of disappointments when doing the research and some ah ha moments where we thought about theories and realized why some wouldn’t be true. We also had some finds that we were surprised with, specifically regarding APT. We’ll be sharing the results on April 14th at 4:45. It should be fun. Our talk has a lot of diagrams, a lot of IDA screen shots, and a great video that Ero made.
 
If you can’t make it to Barcelona, we will be posting our slides and a follow up blog post. Stay tuned! I also have recently updated the slides for Advanced Memory Forensics in Incident Response for Black Hat USA to include an APT case study and a ton of additional information on observing the behavior of malware in memory.

The prizes MANDIANT will be offering to those that place in the top three are:

First Place: $100 gift card to Best Buy
Second Place: Backpack
Third Place: MANDIANT swag

In the event of a tie, we will divide the prize(s) equally.

The submission deadline is April 18th so act fast.
Banking Troubles

Please do not send your submissions to MANDIANT. If you are a winner of the challenge, contact info at MANDIANT after the winners are announced. Peter Silberman and other MANDIANT employees may submit a solution; however, employees are not eligible for prizes. If a MANDIANT employee places in the top three of submissions, all prizes will be allocated to the remaining, non-employees to place in the top three.

Peter and I have been busy planning for CanSecWest in a week. The course, Advanced Memory Forensics in Incident Response, is constantly evolving. It has been about a year and a half since Memoryze was released, and just over a year for Audit Viewer. Honestly, it seems a lot longer, but that is not a bad thing. This week my team will be handing over to QA Windows 2003 64-bit support. While that is in testing, Peter will be making improvements to Audit Viewer that you the user have recommended, and he will be verifying everything works correctly with the 64-bit output. The Malware Rating Index (MRI), which is in Audit Viewer, really changes the case studies in the training. For some exercises, we have to turn MRI off because the malware becomes obvious if you know how to use the tool. I expect MRI will evolve a lot over the next six months as we think of news ways to visualize, sort, and search the data as well as identify new pieces of data to collect. If you are curious how visualization and sorting can help, check out how Harlan Carvey and Chris Pogue use it.

We have gotten a lot of great feedback from the user community, but what Windows operating system support or feature would you like see next? Yes, MANDIANT Intelligent Response has a roadmap, but Memoryze allows us to play a little bit. It is really a labor of love. So let us know what you think. You can reach us at peter.silberman or james.butler plus company name.com. We currently support:

- Windows 2000 SP4
- Windows XP SP2 and SP3
- Windows Vista SP1 and SP2 (better installer coming in next release)
- Windows 2003 SP1 and SP2
- Windows 2003 SP2 64-bit (** next release **)

So if you cannot make the training at CanSecWest in a week, Black Hat USA has just opened their training schedule, and we will be there for the weekend and weekday offerings of Advanced Memory Forensics in Incident Response. I hope to see you soon. Keep your eyes open for official update releases of Memoryze/Audit Viewer and Webinars/presentations.

I’ve had the opportunity to lead a number of MANDIANT’s APT investigations recently, and am looking forward to sharing some of my experiences with our audience. One common thread in many of the investigations I have worked is that the APT will use simpler malware, methods, and techniques – until it no longer works and they are forced to break out something a little more advanced from their arsenal.

The attackers will use more sophisticated methods as needed, and can get incredibly advanced and inventive and just “disappear” from the radar of responders if they really have to.  There has been a lot of chatter on the Internet lately about recent attacks and how the malware and the Command and Control channels aren’t very sophisticated.  But why use sophisticated techniques if you don’t have to?

Think about it – if you are a car thief and the car you are going to steal is not locked and has the key in the ignition – why pick the lock and hotwire the car? It doesn’t mean that the thief can’t pick the lock; it just means they don’t need to.  That same thief may be capable of breaking in to a car that has a locked door, a car alarm, the club, and low-jack – and still get away with it if they are advanced enough and really want the car bad enough (think “Gone in 60 seconds“) .  We have seen everything from the very simple – placing malware in a user’s start-up folder (yes, I actually saw this on one of my engagements) – to the pretty advanced – malware that dropped an NDIS driver capable of monitoring and modifying network traffic at the kernel level, implementing its own TCP/IP stack in the kernel, and providing remote access to a machine that would bypass host-based firewalls, IPS…etc.

During the webinar we will talk about the techniques the attackers use and will go into more depth on a few of the case studies in our recently released M-Trends report.

Oh, and you may be asking yourself what the link is between the name of the webinar “Silent But Deadly”, and what we will be discussing.  We have seen evidence of the APT active and undetected in many victim networks for very long periods of time – up to years in some cases.  Hence, the “silent”.  And, while the result of these prolonged intrusions may not be deadly, they can often be costly, which is very bad for business.

We hope to see you on Thursday!

The webinar entitled Malware Behaving Badly is on Thursday, February 18, at 2:00 p.m. EST. The webinar title is a cute play on my DOD Cyber Crime (DC3) talk where I first introduced Malware Rating Index (MRI) into Audit Viewer (which is available for download).

If you saw my DC3 talk or viewed the slides and are wondering, “hey is this the same talk?” the answer is…well a little bit. The webinar will build off of a lot of the behaviors and theories I discussed at DC3. We will be addressing new behaviors as well as looking at APT vs Mass Malware behaviors.  I’ve added two new configurable behaviors to MRI and did enough research to scrap a third. I’ll share those as well as give more real world examples of how malware exposes itself in memory.

For example the below listing shows the keylogger, the process and the file handle that process has. The file handle is actual the log file the key logger is writing too.

If you didn’t catch my DC3 talk and didn’t understand the slides this is a good time to get an updated version of the talk. I’m going to focus on malware behavior, what it does when it’s installed that makes it stand out in memory. We will cover APT and Mass Malware, and specifically where we see their behaviors intersect. Some of these behaviors are horribly simple, i.e. flag svchost launched from directories other than \windows\system32. Some are as simple but may not be as obvious, for example flag svchost, or iexplore if they have a process handle to cmd.exe. These are rules that should never be true.

When discussing rules, I use that term loosely. Basically in Audit Viewer you now have the option to configure all this information. If you go to Operations -> Configure Malware Rating Index you can configure all these things and a few more not mentioned in this post but mentioned in the webinar. We will wrap up the webinar like always with a live demo. Live demos are the most fun really, it’s like NASCAR except it’s just reputation not lives on the line.

I hope you can join us, it should be fun.

If you would like to learn more in-depth about how physical memory analysis works, use Memoryze and Audit Viewer, understand MRI, or write your own malware rules, join Jamie and I at the CanSecWest training. CanSecWest specializes in technical, hands-on classes with an extremely low student-teacher ratio.

Historically, compromise data has been exchanged in CSV or PDFs laden with tables of “known bad” malware information – name, size, MD5 hash values and paragraphs of imprecise descriptions supplemented by ad-hoc exchanges between targets.

MANDIANT, inspired by field pressures, operation after operation, imagined a way to exchange not only indicators of specific compromises but structures which formalize the human-intelligence of decision-making, rules, exceptions, and ongoing adaptability. Our Indicators of Compromise (IOCs) were shaped operationally detecting real-world threats. We help our clients detect the APT right now, and they’re exchanging information about it using IOCs.

Conventional compromise datasets consist of table after table of immediately-stale data capturing few, if any, relationships. An Indicator of Compromise (IOC), however, is a Boolean decision tree that discriminates an indicator from a false-positive, theory from ground truth. What’s more, when you discover an exception or extension to a well-known-IOC you can describe it concisely and proactively, authenticate its source and re-evaluate your existing data to detect new instances of old compromises. This way, as a threat group adapts to your detections, you retain an IOC’s identity and maintain the value of intelligence shared with other targets over time.

Importantly, IOC is industry-standard XML so you already have tools and a community of experts who can comprehend, transform, and leverage new data immediately. Unlike many XML standards however, it’s simple – developed operationally with an eye toward staying adaptable, transformable, and scalable. IOC describes relationships which indicate compromise – this makes the format resilient to new data formats, data sources and decision engines.

At DoD CyberCrime 2010 MANDIANT will formally release this format and tools to leverage it in your investigations today. We’ll have full coverage of the release on M-unition – stay tuned.

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.

MANDIANT has over seven years experience conducting Advanced Persistent Threat (APT) intrusion investigations for the U.S. government, the defense industrial base and commercial organizations.  During that time, we’ve learned many things, and we want to share our lessons learned with the security community.  A team of our APT experts has been working diligently on a report that we call “M-Trends.”   M-Trends focuses on what the APT attackers do and how they do it.

Some highlights from “M-Trends” include:

• The APT isn’t just a government problem; it isn’t just a defense contractor problem; and it isn’t just a military problem. The APT is everyone’s problem.
• No target is too small, or too obscure, or too well-defended. No organization is too large, too well-known, or too vulnerable. It’s not spy-versus-spy espionage. It’s spy-versus-everyone.
• Classic “prevent and detect” techniques do not effectively counter the APT. The attackers can easily defeat normal defenses. They successfully evade anti-virus software, network intrusion detection and under-equipped incident responders. They use sophisticated techniques to conceal their presence: hiding malware on their target’s own hosts and exfiltrating data in its own network traffic.   A staggering 100% of APT malware identified by MANDIANT made ONLY outbound connections from victim networks, 83% of which used TCP port 80 or 443.
• The APT’s goals are twofold:
  • to steal information to achieve economic, political and strategic advantage.
  • to establish and maintain an occupying force in their target’s environment, a force they can call on at any time. When the APT wants additional data from a target, they don’t need to re-establish a presence. They simply call on their existing assets, locate, steal and exfiltrate the data they need.

We will introduce “M-Trends” at a launch party during the 2010 DoD Cyber Crime conference in St. Louis, MO.  The report authors will be there to answer your questions and share their knowledge.  If you’ll be in St. Louis stop by and see us on Wednesday, January 27 from 6- 9 in the Crystal Ballroom at the Renaissance Grand.

Register for a copy of “M-Trends” and keep your eyes peeled to our blog  and http://www.mandiant.com for the official release of “M-Trends.”

Between informational sessions on the latest cyberspace issues, stop by MANDIANT’s booth (#51) to speak with our knowledgeable staff and gain insight into how we differ in response to cyber security incidents. Don’t forget to grab a souvenir stress ball once we have answered all your questions!

Booth Staff:

• Kevin Albano – Consultant
• Michael J. Graven – Director
• Tim Treat – Program Manager

I know you’re wondering,  ‘Should I be interested in this talk?’ The answer is unequivocally yes. First, you get to hear my and Ero’s angelic voices, which alone is worth the price of admission (free).

Second, this talk runs the gamut of information. Ero will discuss volume, how much VirusTotal sees on a day-to-day basis. He will also cover popular families (I bet you can’t guess which is the most popular, and no it doesn’t start with my and end in doom). Ero will also discuss obfuscation, what trends Virus Total is seeing, what kinds of packers, etc.

I will discuss the Advanced Persistent Threat, specifically speaking about the malware these attackers leave behind. I will discuss how the malware commonly behaves, what it can look like, and why it’s so hard to catch these guys.

You will get interesting statistics like what percent of APT backdoors are detected by any engine VirusTotal supports. You might also see a statistic like what percent of APT uses encryption when communicating.

We’ll cover information that can be interesting to a network administrator trying to protect his company, a CSO who wants to understand the threat landscape better, forensicators who are trying to catch these guys, malware analysts who are curious about behavior, and those who just want to hear our voices!

Hope you guys can join us for a good time, I know Ero and I really enjoyed giving this talk at Source Barcelona and are looking forward to doing it again.

You can sign up for the webinar here.