mercredi 3 octobre 2012
Setting up a malware analysis environment
Buster Sandbox Analyzer (BSA) is a tool that has been designed to analyze the behaviour of processes and the changes made to system and then evaluate if they are malware suspicious.
The changes made to system can be of several types: file system changes, registry changes and port changes.
A file system change happens when a file is created, deleted or modified. Depending of what type of file has been created (executable, library, javascript, batch, etc) and where was created (what folder) we will be able to get valuable information.
Registry changes are those changes made to Windows registry. In this case we will be able to get valuable information from the modified value keys and the new created or deleted registry keys.
» read more
lundi 1 octobre 2012
Looking at Mutex Objects for Malware Discovery and Indicators of Compromise.
Mutex (a.k.a. mutant) objects, which are frequently used by legitimatesoftware, can also help defenders discover the presence of malicious programs on the system. Incident responders can examine the infected host or reverse-engineer malware to identify mutex names used by the specimen, which will allow them todefine the signs of the infection (a.k.a. indicators of compromise). Let's take a look at how mutex objects are used and what tools are available to identify them on a system.
How Programs Use Mutex Objects
Programs use mutex ("mutual exclusion") objects as a locking mechanism to serialize access to a resource on the system. Consider the following explanation by Microsoft: "For example, to prevent two threads from writing to shared memory at the same time, each thread waits for ownership of a mutex object before executing the code that accesses the memory. After writing to the shared memory, the thread releases the mutex object."
The Use of Mutex Objects by Malware
Malicious software often uses mutex objects for the same purpose as legitimate software. Furthermore, malware might use a mutex to avoid reinfecting the host.For instance, the specimen might attempt to open a handle to a mutex with a specific name. The specimen might exit if the mutex exists, because the host is already infected.
Consider the renowned Flame malware. According to FireEye, one of this specimen's components created "numerous mutexes in order to synchronize copies of itself simultaneously injected into various core Windows processes (e.g., services.exe, iexplore.exe, winlogon.exe) that are already running." FireEye documented the mutex names whose presence indicated that the system was infected with Flame.
As another example,the Pushdo/Cutwail bot created mutex objects that were used to "coordinate its highly multithreaded communication" according to TrendMicro. The mutex objects names were"gangrenb," "germeonb," "crypt32LogOffPortEvent," etc. As yet another example, the default name of the mutex set by the popular Poison Ivy backdoor is ")!VoqA.I4"; this was the case during a targeted attack against a large Swedish company documented by the Internet Storm Center.
Using Mutex Values to Find Malware
When examining a potentially-infected system, we can look for names of mutex objects known to belong to malicious programs. This approach works particularly well when you've already identified malware on some enterprise system, determined the names of its mutex objects, and are examining other systems to see whether they are infected. Malware databases such as ThreatExpert include mutex names when describing malware, providing another source of potential signatures based on mutex objects.
Moreover, it's relatively uncommon for legitimate programs to use mutex names that are completely random; you might use this heuristic to identify infected hosts even without searching for a specific mutex names. (See Gary Golomb's post that touches upon this topic.) A command-line tool called CheckMutex can query the local host for the presence of a mutex object with a specific name. The author of CheckMutex, Jaime Blasco, also provides a command-line utility called EnumerateMutex for generating a list of all active mutex objects on the system, you you can examine the list for the names that interest you.
Another way to enumerate all mutex objects from the command line involves Microsoft's Handletool by Mark Russinovich. This utility lists various handle types that are open on the system; to list only mutex objects look for those of type "Mutant" like this:
handle -a | findstr Mutant
GUI tools Process Explorer and Process Hacker tools can list open handles on the host, including those that refer to mutex objects. Both tools include an option to search for an open handle or DLL by name. The Performance Monitor tool, built into Windows, also offers these capabilities, as outlined by Mark Baggett. Here's what this feature looks like in Process Hacker:
It is also possible to search for mutex names when examining a memory snapshot of a compromised system. For instance, the popular memory forensics framework Volatility can enumerate mutant values using the "mutantscan" command.
As you saw in this article, mutex names can be used for creating indicators of compromise, which would allow incident responders to identify hosts infected with malware that uses those mutex objects. It might also be possible to define heuristics that alert when unusually-random mutex names are discovered on the host, though this approach could produce some false positives. There are several command-line tools to list mutex names, though there is room for maturing this approach to malware discovery. Related posts:
How Programs Use Mutex Objects
Programs use mutex ("mutual exclusion") objects as a locking mechanism to serialize access to a resource on the system. Consider the following explanation by Microsoft: "For example, to prevent two threads from writing to shared memory at the same time, each thread waits for ownership of a mutex object before executing the code that accesses the memory. After writing to the shared memory, the thread releases the mutex object."
The Use of Mutex Objects by Malware
Malicious software often uses mutex objects for the same purpose as legitimate software. Furthermore, malware might use a mutex to avoid reinfecting the host.For instance, the specimen might attempt to open a handle to a mutex with a specific name. The specimen might exit if the mutex exists, because the host is already infected.
Consider the renowned Flame malware. According to FireEye, one of this specimen's components created "numerous mutexes in order to synchronize copies of itself simultaneously injected into various core Windows processes (e.g., services.exe, iexplore.exe, winlogon.exe) that are already running." FireEye documented the mutex names whose presence indicated that the system was infected with Flame.
As another example,the Pushdo/Cutwail bot created mutex objects that were used to "coordinate its highly multithreaded communication" according to TrendMicro. The mutex objects names were"gangrenb," "germeonb," "crypt32LogOffPortEvent," etc. As yet another example, the default name of the mutex set by the popular Poison Ivy backdoor is ")!VoqA.I4"; this was the case during a targeted attack against a large Swedish company documented by the Internet Storm Center.
Using Mutex Values to Find Malware
When examining a potentially-infected system, we can look for names of mutex objects known to belong to malicious programs. This approach works particularly well when you've already identified malware on some enterprise system, determined the names of its mutex objects, and are examining other systems to see whether they are infected. Malware databases such as ThreatExpert include mutex names when describing malware, providing another source of potential signatures based on mutex objects.
Moreover, it's relatively uncommon for legitimate programs to use mutex names that are completely random; you might use this heuristic to identify infected hosts even without searching for a specific mutex names. (See Gary Golomb's post that touches upon this topic.) A command-line tool called CheckMutex can query the local host for the presence of a mutex object with a specific name. The author of CheckMutex, Jaime Blasco, also provides a command-line utility called EnumerateMutex for generating a list of all active mutex objects on the system, you you can examine the list for the names that interest you.
Another way to enumerate all mutex objects from the command line involves Microsoft's Handletool by Mark Russinovich. This utility lists various handle types that are open on the system; to list only mutex objects look for those of type "Mutant" like this:
handle -a | findstr Mutant
GUI tools Process Explorer and Process Hacker tools can list open handles on the host, including those that refer to mutex objects. Both tools include an option to search for an open handle or DLL by name. The Performance Monitor tool, built into Windows, also offers these capabilities, as outlined by Mark Baggett. Here's what this feature looks like in Process Hacker:
It is also possible to search for mutex names when examining a memory snapshot of a compromised system. For instance, the popular memory forensics framework Volatility can enumerate mutant values using the "mutantscan" command.
As you saw in this article, mutex names can be used for creating indicators of compromise, which would allow incident responders to identify hosts infected with malware that uses those mutex objects. It might also be possible to define heuristics that alert when unusually-random mutex names are discovered on the host, though this approach could produce some false positives. There are several command-line tools to list mutex names, though there is room for maturing this approach to malware discovery. Related posts:
Inscription à :
Articles (Atom)