The internet community took notice of DLL hijacking when a link to a security advisory was being passed around Twitter and being discussed by various security industry figureheads.  The advisory was produced by a company named Acros Security and can be found here: http://www.acros.si/aspr/ASPR-2010-08-18-1-PUB.txt. I was naturally curious about this as it was published only one month after my blog post on the topic and sounded at first very similar.  People have been taking this technique and discovering vulnerabilities in many applications, as is visible in the enormous spike in activity on exploit-db.com (http://www.exploit-db.com/local/) on August 24^th and 25^th.

The key difference in this technique as opposed to the one I described is that it relies on a DLL being placed in the Current Working Directory of the software versus being placed in the Application Directory.  In my post I described the scenario in which almost every program is vulnerable to DLL Search Order Hijacking when a DLL can be written to the directory that contains the EXE of the program.  The directory containing the EXE is always the very first location in the DLL search order (except for KnownDlls) so the problem is quite wide-spread.  This technique makes a great persistence mechanism for malware but is a poor way to attempt to get initial code execution on a system.

The problem currently making headlines comes down to the fact that when most programs recursively enumerate files, they do so by setting the current working directory to each directory they find before examining the files found in that directory.  By setting the current working directory to a location, you expose DLLs found in that directory to be a part of the DLL search order and in some cases they will be loaded.  The current working directory is fifth in the DLL search order with SafeDllSearchMode enabled (the default on most systems these days) and second in the search order otherwise.  Strictly speaking, with a position farther down the chain of DLL search order it is more difficult to exploit this than if one has access to the application directory itself.  The reason for all the attention this has received is that many applications will traverse files across a network share, allowing remote infection by applications that both set current working directory for file traversals and have a mechanism where a DLL can be caused to load based on the file type or contents.  The now famous example of this is the iTunes example from the advisory where iTunes sets the current working directory to the directory of files it is scanning, then loads a DLL under some circumstances based on the content of the files it finds.  With current working directory potentially set to a network share containing a batch of music files, a specifically named rouge DLL could be loaded by the iTunes application.  This technique is a great way to get initial code execution on a system but makes a poor malware persistence mechanism.

Many security vendors have been discussing solutions to the problem lately.  Many recommend loading DLLs by explicit paths, which is a valid approach.  Others have been pressing Microsoft to alter the behavior of DLL loading within operating system, which creates a nightmare of backward compatibility problems.

If setting the current working directory during file traversal leads to potential vulnerabilities in some applications, the logical question to ask is do applications really need to set current working directory to traverse files?  The answer is no.  Setting current working directory leads to slightly simpler recursive code which is why it was chosen in the first place. All API documentation on the topic of traversing files in a Win32 environment use this approach, including Microsoft’s MSDN documentation as well as the two Win32 System programming books on my bookshelf “Windows via C++” and “Windows System Programming”.

When a programmer sets out to write code to traverse files they will typically not reinvent the wheel and will most likely use reference code found on the internet or in a book.  This is not a knock on the programmers who use reference code, file traversal in Win32 is actually somewhat complicated to understand and implement correctly, especially for the novice programmer.  Reference code leading to vulnerabilities is nothing new.  For example, open any book on making web database front-ends and you’ll probably be writing code that is profoundly vulnerable to SQL injection.

Traversing files without setting current working directory involves building full path strings recursively.  The reason this code was mostly likely not chosen to be the reference implementation of file traversal is that it requires string manipulation, which can be error-prone and insecure if done improperly, and requires slightly more code.  Let’s examine the pseudo-code for each approach.

Recurse(path)
{
    If path is a file
    {
        process_file(path)
    }
    Else if path is a directory
    {
        Save current directory path with GetCurrentDirectory()
        SetCurrentDirectory(path)
        Loop over all directory entries with FindFirstFile(“*.*”) and FindNextFile()
        {
             Recurse(directory entry)
        }
        SetCurrentDirectory(saved current directory)
    }
}

In the code above there isn’t any string concatenation taking place. Each time we recurse down a directory we saved our current directory, changed the directory before recursing, then restored the current directory when the recursive branch finished.  The vulnerability lies in what specifically happens when your application does something like process_file() above.  If process_file() for your application could potentially result in a DLL loading, then the current working directory is set to the directory of the file you are processing.  Thus the operating system will include this directory in its list of places to look for the DLL.  Let’s examine a different high level pseudo-code that won’t leave us vulnerable to this attack.

Recurse(path)
{
    If path is a file
    {
        Process_file(path)
    }
    Else if path is a directory
    {
        Concatenate the path with the wildcard “*”
        Loop over all directory entries with FindFirstFile(path with wildcard) and FindNextFile()
        {
            Concatenate the path with the directory entry name
            Recurse(new directory entry path)
        }
    }
}

Pseudo code is great for seeing the big picture but the problem, as I have stated, is that the skeleton code people grab from reputable documentation sources which uses the technique that isn’t appropriate for their application.  I have written a skeleton file traversal program which uses the string concatenation technique as shown here.  I’ve included the same skeleton program that uses the current working directory approach in case any researcher is curious to compare. Both the vulnerable and non-vulnerable skeleton file traversal code can be downloaded here: filetraverse_skeleton_code

Focus

One of the biggest challenges during an investigation is staying focused. It is all too easy to chase shiny objects, and sometimes even not-so-shiny objects, and never figure anything out. So in this part, I’ll talk about what Mandiant does to help prevent an investigation from falling off track.

According to the Carnegie Mellon Software Engineering Institute:

“When an incident occurs, the goal of the CSIRT is to control and minimize any damage, preserve evidence, provide quick and efficient recovery, prevent similar future events, and gain insight into threats against the organization.”

I think that statement does a great job summing up what the incident response process is all about, and what Mandiant commonly focuses on. But I have something to add. Mandiant pays special attention to specific high-level questions that need to be answered.

Questions

Based on discussions with our customer, we form high-level questions early on in the investigation. These questions define what topics will be in the executive summary of our final report. They also provide guidance for all investigative activities – the team should only perform tasks that contribute to answering those questions.

During an investigation, I consider myself a fact-finder looking for facts to answer those questions. I establish and search for facts that describe the incident. So it’s very important to start the investigation on solid ground. We start by discussing the incident, in technical detail, with our customer. We directly verify and examine all initial facts about the incident by acquiring the data that shows the facts – forensic images, firewall logs, etc. Once we know we’re on solid ground, we start to fan out – thinking of ways to look for evidence associated with our initial facts.

As we proceed, leads can take us down many different paths, some that help and some that hurt. To stay focused here, we take an old school approach: Who, What, When, Where, Why and How.  Staying focused on answering these questions will help us Find Evil, and eventually Solve Crime.

Context

One very important aspect that will help is to develop a clear picture of the context of the incident and evaluating every new investigative action against it. This will help keep the team focused and efficient. Here are examples scenarios Mandiant has seen challenge an IR team’s ability to stay focused:

Problem: The team is not keeping a list of affected systems, malware found, indicators of compromise or dates and times of significant events. Also, no one is keeping a list of evidence gathered, outstanding tasks or responsible persons. Each day, team members are thinking someone else is working on a critical task but things are slipping through the cracks.

Solution: Assign a single team member to maintain a Web page, document or spreadsheet with all that information.

Problem: Team members are spending a lot of time analyzing data. Forensic images are scrutinized in painful detail. Lead generation is slow.

Solution: Before a team member begins analysis on any type of data, provide them with the following:

• Lead information (i.e., what do we already know)
• A list of questions you want answered
• A report template
• Discuss the elapsed time expected to complete the analysis
• Request the analyst inform you as soon as he or she thinks they are not on track with expectations

Problem: An investigation clearly identifies malware associated with the incident on a computer. While performing detailed analysis, additional malware is identified on the system. The team extracts the malware, performs analysis, and begins searching for indicators of that malware on other systems. They find the malware is on additional systems and begin investigations of those. Unfortunately, the malware was unrelated to the incident at hand, and the team wastes days of work.

Solution: A quick review of the context of the finding – as simple as checking the date the malware was created.

Problem: The team provides IP addresses and domain names to the proxy administrator to search for. While searching for those indicators, the administrator begins to look at the logs more closely than they ever have before. The administrator discovers entries that seem suspicious. They are reported to the team. The team begins to investigate these entries – responding to the computers responsible for the traffic. The team finds no correlation between these systems and the systems involved with the incident at hand.

Solution: A quick sanity check on the reported entries – are they similar to other known activity? Are they within the time frame of known activity?

Summary

Mandiant has found that the biggest challenge to most investigations is in how they are managed. We’ve found that sticking to the basics – documentation and communication – go a long way to help us stay focused to Find Evil and Solve Crime.

Stay tuned to M-unition for my next post, where I’ll discuss collecting and analyzing data that’s useful on an IR. I’ll talk about some challenges and provide suggestions to help.

Sockets

The first group, sockets, is the most widely known as it is the same basic networking API found on Unix. It provides a somewhat raw session level access to a TCP or UDP session.  It is provided primarily by the DLL ws2_32.dll, though it has a storied history.  Any application using the socket API must manually craft any higher level protocol such as HTTP.  A socket object is created with a call to the function socket().  It is during this call where the protocol is specified, TCP or UDP.  For a TCP client like most malware backdoors, the function connect() must be called, which performs the TCP three-way handshake and paves the way for reading and writing of data.  A server program on the other hand will typically call bind() and listen() to wait for connections (although bind() can also be used client side to force a socket to a specific egress port).  The functions send() and recv() are frequently used to transfer data across the wire for TCP connections and sendto() and recvfrom() are traditionally used for UDP connections.  From a malware analysis perspective this makes things simple, if I need to understand what information a piece of malware is expecting in response to its beacon packet I can typically look for calls to the recv() function and see how the code that follows inspects the data it reads from the wire.  On Windows though, sockets can be used interchangeably with most operations as if they were a file handle.  For example, a process (like cmd.exe) could be spawned with a network socket specified as its standard input and standard output and that process would automatically communicate across the network.  To learn the socket API in-depth I recommend reading the late W. Richard Stevens’ classic book UNIX Network Programming Volume 1.  The drawback to using the Socket API is that interacting with any higher level protocol such as HTTP must be done so manually.  This allows a lot of flexibility in how the malware crafts its requests but everything must be laid out explicitly.  Malware authors will frequently introduce subtle nuance differences between the way their HTTP traffic looks on the wire and the way most web browsers look.  These small differences make great network signatures!

WinInet

The WinInet API requires much less work than the socket API.  It is a convenience API which simplifies the interaction to higher level protocols such as HTTP, FTP and even GOPHER!  To begin using the WinInet API to talk to a remote host you first need to call InternetOpen() followed by InternetConnect() or InternetOpenURL().  Once the internet has been opened and a connection established, to perform and HTTP request you can call the functions HttpOpenRequest() to make a request handle and HttpSendRequest() to send the request.  InternetReadFile() may then be called to read any response from the server.   It can also be used to read data from an FTP session.  The InternetWriteFile() function can also be used generically in place of any protocol specific function where data needs to be sent across the wire.   The HTTP functions provide the programmer the ability to configure most of the options one would expect in an HTTP request header such as the User-Agent string.  Not all of these values have to be specified though, and the system default will be used if none is specified.  The malware programmer doesn’t have as much flexibility to introduce subtle anomalies in the request structures though like they can with sockets, and left with default settings the malware’s HTTP requests will look virtually identical to legitimate Internet Explorer traffic on the network.

URLMon

The URL Monikers API provided by the DLL urlmon.dll provides yet another API for performing internet communications.  In the back end it uses COM but I choose to list this as a separate category from the later discussion of COM because using this API is an abstraction away from the ugly, obscure-t0-reverse methods of direct COM interaction.  The most popular function in the URLMon arsenal, from a malware perspective, is the one-punch knockout function URLDownloadToFile(). Rarely in the Win32 API does one function do so much work.  You provide this function a URL (for any protocol IE understands), a filename and it uses COM to force Internet Explorer to download the resource to the specified filename.  This is very popular with dropper malware which simply needs to download an EXE from a website and launch it.  You might also run into the URLDownloadToCacheFile() function which will download a specified URL to the browser cache and return the name of the file it downloaded to.  URLOpenStream() and URLOpenPullStream() can be used to download a URL to a buffer in memory, but these functions are rarely used in malware.

Controlling Internet Explorer with COM

Using COM for malware command and control has a number of advantages for the malware author.  From a live response/volatile data/memory analysis perspective it obscures the source of malicious traffic because all communication with the remote host will be performed within an iexplore.exe process instead of the malware process.  From a reverse engineering perspective it makes things complicated because it is not immediately clear that the malware is doing network communications at all when first inspected with static analysis.  COM has fallen out of fashion with many of today’s programmers and is less understood than many other technologies used in modern software.  Malware analysts may be particularly unfamiliar with the inner workings of COM, depending on the programming background in the Win32 world.

Before any COM object can be instantiated, the function CoInitialize() must be called to initialize the COM library.  Once this is successfully initialized a call can be made to CoCreateInstance() to create an instance of a particular COM object, such as Internet Explorer.  In order to understand which object is being instantiated at this point you must inspect the first argument to the CoCreateInstance() function, which will be a CLSID value which is a unique identifier for a COM object.  Here is the call to CoCreateInstance() found in a malware sample which used COM:

At first glance it’s difficult to tell what object this function is instantiating because IDA simply shows you the data type of the first value instead of any type of meaningful interpretation of it.  The first argument in this example code is a global variable (a constant actually) that exists at some location in the binary that has been given the label “rclsid” by IDA Pro.  If you double click on this first argument IDA Pro will take you to view the variable as it would look in memory:

This CLSID value is recognized as a data structure by IDA and is shown here broken into its components.  The Human-readable way to represent this CLSID value is “{0002DF01-0000-0000-C000-000000000046}”.  It would be nice if there were an IDA script to automatically name these values, but in the mean time you can look them up manually in the registry.  By opening regedit and browsing to the key HKEY_CLASSES_ROOT\CLSID you can see a rather long list of subkeys, each named with a CLSID value.  By finding the subkey name which matches the hexadecimal values you see in IDA Pro you can identify what the object name is that the program is requesting, which is stored in the default value of the key.  Here is a screen shot of regedit showing the key for the CLSID shown in the example code above:

So it appears that our malware sample is making an instance of the Internet Explorer object!  In order to use any functionality from this object the malware must make use of the last argument to the CoCreateInstance() function (which was labeled “ppv”).  This parameter is a pointer to pointer to receive a newly allocated data structure containing all the pertinent data for this object, most notably function pointers.  The list of functions available is documented here: http://msdn.microsoft.com/en-us/library/bb159694.aspx.  To see the Internet Explorer object in action from a source code level please take a look at this article: http://support.microsoft.com/kb/167658.

The most important function call to this COM object we need to recognize as reverse engineers is the call to the function Navigate() or Navigate2().  This is what actually accomplishes the HTTP request which may also contain POST data or a parametrized GET, and thus transmit data to the remote command and control server. The following screen fragment shows the call to the Navigate() method of the IE COM object as seen from IDA Pro:

In this fragment we see the ppv value being accessed, which is what was populated from the call to CoCreateInstance().  A function is being called from within this data structure.    This function is at offset 2Ch from the beginning of the ppv data structure, and you can tell that the binary is calling this function because the call instruction accesses this specific offset from the beginning of the structure (“call dword ptr [ecx+2Ch]“).   There is no clear-cut way to go directly from the Microsoft documentation of this COM interface to seeing the actually internal offset used by each member function, so I made a small test application to simply reference each function.  I then disassembled my test application and could see the clear mapping of offsets to member functions.  The following table is a mapping of the commonly used member functions (by malware specifically) and their associated offsets as seen in a call instruction:

Final Thoughts

My goal with this article was to make more malware analysts and incident responders aware of the spectrum of communication techniques available to malware authors and to make analysts recognize and be able to begin reverse engineering the COM technique specifically.  There is certainly a need for more tools and techniques in this area but it all begins with awareness and understanding.  One thing to take away from this is that as a malware analyst it is not enough to simply know assembly language.  You must gain a working knowledge of the APIs and you must be rigorous, if not downright tenacious, in your appetite to learn new facets of the APIs as you encounter them.  If a malware analyst disregards calls such as CoCreateInstance() without deeper inspection due to their lack of understanding of it, they potentially will miss a critically important component of the malware’s operation.

1. Remedial efforts usually take more effort and determination than anticipated.  It is a good principle to begin managing the expectations of the business units as soon as possible, ensuring they are aware that the remedial efforts may involve continual effort, resources, and periodic adjustments based on the dynamics of the ongoing threat.
2. Good remediation plans often fail because determination wanes if each phase of the plan is not short and concise.
3. An ineffective remediation is initiated because the plan was implemented prior to understanding the tools and techniques of the intruder.
4. An ineffective remediation plan was initiated because the remediation plan took too long to develop, allowing the compromise to become so widespread that remedial efforts become very time consuming and costly.
5. The remediation plan fails because accountability for its execution is not clearly assigned to an individual.  Each business unit should assign an individual who becomes responsible for the implementation of the plan.
6. Remediation fails due to lack of resources – lacking the personnel, technology and processes to follow through on the remediation plan.
7. Remediation fails because the organization tipped off the attacker.  In past investigations the following actions have tipped of the attacker:
   • Removing compromised systems as you discover them
   • Changing one-off domain admin passwords when you see them used
   • Blocking Command and Control (C2) channels as they are identified
8. Remediation fails because the organization does not or cannot disconnect from the Internet while undertaking remediation activities.

In order to develop and execute an effective remediation plan, not only must you understand these points, but you must also execute your remediation at the right time.  Remediating too early does not help your organization defend your networks, and remediating too late ensures you have lost all your trade secrets to the adversary.  Therefore, below are some key criteria for you to use in order to assess your remediation “timeliness”:

You are remediating early, and entertain higher risk of re-compromise or not fully remediating the current compromise when:

• Host-based indicators of the current compromise (the attacker’s fingerprints) are unknown
• Network-based indicators are unknown or transaction based
• New compromised hosts are still being detected at a high rate (more than one per day)
• There seems to be no established pattern to assist your organization in anticipating the next compromised host
• There is little coordination between business lines (Staff) concerning remediation

You are potentially remediating too late when:

• Host-based indicators are becoming less reliable (they are not hitting on anything)
• Network-based indicators are becoming less reliable
• You know the attacker has been active and they just “vanish”
• Staff motivation and concern has waned
• Remedial activities have evolved from corporate-wide efforts to independent “splinter cells”

You are in the strike zone and remediating at the right time when:

• Host-based indicators are stable
• Network-based indicators are stable
• The delta to detect new compromised hosts is shrinking consistently
• Your organization is postured to actively identify and address the “next generation” of attacks – In many of our investigations we see the attacker, or a different attack group, return.  We have seen it take 3 days, 3 weeks, or even 3 months – but inevitably they try and come back.  Your organization has information that is deemed valuable and the attackers won’t just “go away” when you kick them out).
• There is active communication and coordination between business lines (Staff) concerning remediation

Once you understand when to time the execution of your remediation plan, you should execute it.  MANDIANT will be posting numerous blogs throughout the next several weeks to provide the technical details behind many of the longer term remediation strategies that cannot be implemented prior to eradicating the current incident.

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.

A caveat within MRI I that I want to talk about is Process Path Verification. This rule set is very powerful but there are two ways to define to paths. Neither is documented because currently there is no documentation on MRI.. The first method of specifying a process path is to specify an absolute path such as this:
calc.exe:\windows\system32

MRI interprets this as the only valid path for calc.exe is \windows\system32\calc.exe. However, if I wrote the rule like:
calc.exe:\windows\system32\

MRI would interpret this as calc.exe can be run from any sub directory as long it’s a sub directory within \windows\system32\*

The reason this is important is it gives you flexibility in writing definitions. If I don’t want to specify the exact location of iexplore.exe I can say it needs to be launched from \program files\. This may prove to be too loose, and I may change this behavior going forward. For now you have the flexibility to specify absolute paths or sub paths.

The next “undocumented” tidbit that I want to discuss is within two behaviors. These behaviors actually have the ability to use regex when trying to match up their values. I did not build the regex option into the UI so it has to be manually added to the AuditViewerConfig.xml. The two XML lists that can take regex expressions are IgnoreFilesList, and ProcessSuspiciousHandleList. The regex elements are, IgnoreFileRegex, and HandleRegex. An example IgnoreFileRegex looks like:
<IgnoreFileRegex>mshist.*\\index.dat</IgnoreFileRegex>

This rule specifies that any file matching this regular expression should be ignored when doing process scoring. You can get creative just be careful.

An example HandleRegex looks like:
<HandleRegex>*:.*-7$:mutant:known conficker mutant</HandleRegex>

It breaks down like this:
Process: Regular Expressions : handle type: description

It breaks down like this:
Process: Regular Expressions : handle type: description

This allows you to get more out of your suspicious handles definitions.

Finally, I’d like to take a second to reiterate something I stated at DC3. The “Verify Digital Signatures” option in Memoryze and Audit Viewer wizard can ONLY be run when doing live memory. It is not possible to enable it when doing dead memory analysis. Which means the address scoring is not possible on dead memory, behavioral analysis still works on dead memory. If you are going to acquire memory, please run live analysis jobs as well as acquisition. This way you get the most information possible off the machine. The second thing I wanted to reiterate is that verify digital signatures is great, it really helps potentially speed up an analyst’s job. However, we are only verifying the digital signatures exist and are valid on disk. We are not verifying the module in memory hasn’t been modified. If a userland rootkit exists (again shame on the authors) then we won’t report that. It’s important to remember this. Verifying modules in memory short of doing rootkit detection is not a trivial task. The windows loader is a beast, a behemoth it does a lot to make verification in memory to disk is very hard (not impossible). Thanks again for all the interest in M-Trends, Audit Viewer and Memoryze. As always feedback is always appreciated.