Malware Detection Avoidance through Mutexes

Malware Detection Avoidance through Mutexes

Alexios Kotsis

I. Introduction -Background

Malware attacks are increasing exponentially every year and becoming harder to find since they are using various techniques to hide and bypass detection or protection mechanisms. Detecting that malware is big multi-dollar business, and antimalware companies are trying to find signatures and pieces of code that will help them identify them. Hiding and avoid detection of the created malware is a common practice for hackers. One of those methods of hiding is achieved by using mutexes.

A mutex is a legitimate software used by the operating system in multithreaded programs to facilitate the normal job queue process. The same process is also usedby malware software. It is a flag that can be set or upset or more specifically locked or unlocked. The problem it resolves is the unpredictable behavior and rase conditions that result from multiple threads in accessing a resource, mainly if the thread modifies that resource. Mutexes come with two types: the local mutexes (also called unnamed) and the named system mutexes. The unnamed mutexes are found only inside the process while the named ones are located within the operating system and are used for synchronization of the various activities or operations.

Malware, on some occasions, uses mutex objects to coordinate the communication between its various components and bypass re-effecting the same system more than once. We may consider mutexes as the fingerprints of malware. These mutexes have specific names, and typically a malware detection system can look for those known names and spot the presence of malware. There is also the case that the malware creators are using dynamic mutexes, which are harder to detect. In some cases, some malware will avoid using a specific name to avoid detection. Mutexes are also used to discover whether the operating system has an antimalware system activated and is even used in bot wars to eliminate other bots in the system and become dominant.

Mutex static analysis is a powerful tool for malware discovery, family classification, and author fingerprinting. In surprising research, it was found that 15%: of collected worms have the same mutex (2gvwnqiz) 6. Mutex dynamic analysis is more complicated and involves analyzing many processes, each with their own view of memory and the kernel schedules, which are different ones running at different times.

To avoid detection, the malware uses different evasion and masquerading techniques to prevent being registered in the databank of dangerous mutexes, used by the antimalware systems, byusing dynamic techniques in various forms, including web-based and machine language learning.

II. Technical 1 - Mutex Description

We must first determine what a mutex is. Let's suppose we are in a situation where we have a "race condition. "This occurs in multithreaded programs. If there is only one job queue, the first thread will investigate whether the job queue is empty and then will find the job and begins executing it. The second thread will also examine the job queue considers if there is already onein and will assign the same job pointer resulting in the same job has been executed by two threads, at least thus resulting in a segmentation fault. The mutex resolves this condition. It will lock one threat at a time, and if another thread wants to lock too, it will get blocked. The way this is resolved is presented in Figure 1.

This is done by the operating system, which initiates the lock requests. When a mutex.lock() is requested, the thread stall in a lock() and requests it from the operating system, now when the operating system detects a released mutex from the thread, it will pass it to the thread which requires it dedicating only to that thread and nothing else by" try_lock()" which will return "true (if it used will return "false." If another thread call lock(), the OS will block it. A typical mutex generation procedure is presented in Figure 2.

Malware uses mutex in the same way as a legitimate program. The malware will use a mutex to prevent the same host from being reinfected. In most cases, this is done statically, but, in some instances, mutex names which are generated dynamically to evade detection have been reported. The good thing about those processes is that the malware s use mutexes not only to non-sophisticated userland malware but also to kernel level highly sophisticated ones. While the malware tries its best to hide every trace of it in the operating system for proper functioning has its mutex objects unexposed.

For example, the infamous "Flame "malware developed a vast number of mutexes to synchronize duplicates of itself -which were injected simultaneously into several Windows core processes, such as winlog.exe, iexplore.exe, services.exe, etc., which were already running. In another example, the infamous bot "Pushdo/Cutwail" developed mutexes with the use of proper coordination of its extreme multithread communication. The mutex names used were "crypt32LogOffPortEvent", "germeonb,” "gangrenb," etc. In a backdoor example, the infamous "Poison Ivy" the name of the mutex was ")!VoqA.I4” 1. Some of them even have funny, brilliant names such as "don't stop me! I need some money!" "TreaseHunter,” "mr_coolface,” "chinese- hacker-2", "senna spy rock in rio 2001 virus", "Pluguin" or even use a shellcode in a mutex name as "mutexpolesskayaglush*.*svchost.comexefile\shell \open\command %1 %*@".

Mutexes are being used by malware code writers to discover whether an operating system has a security system. This mutex routine is defined in the entry point of the malware. The purpose of this mutex is to determine if the malware is used before. In general, malware code writers are familiar with common malware mutex names which are used by the operating system antivirus program or any other protection system. In the Windows operating system, this is done by using the CreateMutex() API extensively to determine any mutex in the system. The routine at the entry point of the malware activates the API to investigate if the mutex is already there. If the mutex is present, the API gives an error message, which indicates that an antimalware system is installed in the attacked machine. This makes the malware to stop executing and enter a sleeping mode. Typical examples of this technique are the ICEX, SpyEye, and Zeus bots 5.

While some mutexes are evident that there is malware as per example "2qvwnqiz1," with a chance of 100%, as shown in Figure 3, some of them as "local\!liet!mutex" have a 62% chance of being a legitimate mutex and 38% of being malware. There are many mutexes that coexist in malware and legitimate software and also don't share the same uses. The typical approach would be to use sets of mutexes to create unique identification and use it for proper classification decisions. This mutex research approach, though, is slow going. The count of uses a single mutex is used is decreasing from millions to thousands resulting that the majority of mutexes cannot be easily classified as being legitimate or malware. This problem prohibits antimalware designers from creating confidence models and fully automated software for mutex association to either malware or benign samples. Some antimalware designers, though, argue that full automation is not necessary, and with proper tools, human researchers can review and categorize new mutexes as "statistical," "benign: or "malware." A ranking system already exists with many samples as date classified as malware vs. benign that can help researchers in their tasks 6.

The following code is a typical hardcoded mutex creation called: "Alexiosmalware" part of a longer malware program.

1. push offset Name; "Alexiosmalware"
2. push 0 ; bInheritHandle
3. push 1F0001h ; dwDesiredAccess
4. call ds:_imp_OpenMutexW@12 ; OpenMutexW(x,x,x)
5. test eax, eax
6. jz short loc_4010E
7. push 0
8. call ds:_imp_exit
9. push offset Name ; "Alexiosmalware"
10. push 0
11. push 0
12. call ds:_imp_CreateMutexW@12; CreateMutexW(x,x,x)

We can notice on line 4 that the code first checks if there is a mutex called "Alexiosmalware" using the OpenMutex call. If the code gets a return NULL on line 5, it jumps at line 6 over the exit call and continues the execution. In this case, the return value is not a NULL exit to line 8, and the whole process will exit. In case the code continues its execution, we have the mutex creation at line 12 to make sure that all additional parts of the main malware code will exit when they reach this part of the code [11].

There are occasions where we find one bot killing another bot to become dominant. In this case, mutexes come handy by using the OpenMutex() API to find the active mutexes in the system. Which API to use depends on the malicious code writer. This kind of other bot killing was first seen on initial versions of SpyEye with a Zeus bit execution software that used designated commands and named pipes to eliminate Zeus bot from the operating system.

III. Technical 2 -Malware Detection Techniques using mutexes

Mutexes can be found in a live system, on a memory dump, and in an executable. The simplest method of malware detection in a live system is by using standard Sysinternals tools as "Process Hacker" to check what is happening in the system, as in Figure 4. Usually, we have verification in any one of them with proper signatures. In some cases, we will have a malware showing, but that is unlikely. The next step would be to check the system at a lower level.

To do this, we can use a software program called "Redline," which will audit the data, scoring how adverse the findings are and will also organize the large volume of data so the user can visibly detect and ranked as in Figure 5. We must first create a collector of the data to perform an analysis based on memory-based audits, acquire the memory image, and finally analyze and search for malware using indicators of compromise (IOCs). Still, there is a high probability that high false-positive readings will be detected. To overcome this problem, we use mutex detection. We must first collect and leverage a kernel called Object Manager Database, which organizes the object names in the system. We can do this by using an application "WinObj," as in Figure 6. Of all the directory object revealed, the one that has the listings of events, section objects waitable timers, semaphores, and finally, mutexes are the "BasedNamedObjects" as in Figure 7.

Using this information, the simplest solution would be to find the mutexes indicating malware with the signature collection, but this is highly ineffective since malware mutexes are configurable. |In our advantage is the fact that malware mutexes cannot mimic a legitimate mutex and take its name because then we would have duplicate mutex names, and the malware would not load. We can visibly recognize malware mutexes by looking at specific points as differences with legitimate ones.

There are some significant differences between legitimate mutexes and malware ones; these are [8]:

- A difference in the way the strings are formatted
- A difference in the way the special characters are used and distributed inside the string
- A difference in the entropy of the strings
- A difference in length

Since the main function of mutexes is to lock objects, so typical mutex analyzer software, such as "LockPick," are used to filter mutexes (using the previously mentioned differences) and indicate the ones that may be considered suspicious. We then discover the process(es) that are using the mutex and examine all the handles that are held by the process. After forcing a full memory crash dump and analyzing it, using software such as "WinDbg," we can track malware configuration files and string sending in "_begin," such as "servers_begin," kit_hash_begin," "cmd_dll_hash_begin" etc. In a further search of Google we can get the malware's name from the strings. If the string does not appear in the search that more than likely means it is a brand-new malware.

Another typical method to see which mutexes the malware uses is by using http://www.virustotal.com. To demonstrate this, we will use the file "PracticalMalwareAnalysis-Labs.exe" given as a project in "Lab 1 CISC 6680 Malware analysis" by professor Md Zakirul Alam Bhuiyan. As we can see from the results in Figure 8, we can identify, at the bottom of the figure, the malware file created some mutexes, which were:

- Local\!PrivacIE!SharedMemory!Mute x
- Local\_!MSFTHISTORY!_
- Local\c:!users!administrator!appdata!l ocal!microsoft!windows!history!histor y.ie5!
- Local\c:!users!administrator!appdata!l ocal!microsoft!windows!temporary internet files!content.ie5!
- Local\c:!users!administrator!appdata!r oaming!microsoft!windows!cookies!

IV. Technical 3 - Evading Detection

The simplest method of avoiding detection and hide mutexes is by compressing the file using Zip, RAR, and other programs. There is a good chance that some malware detection will not detect it. Again, we took as an example the compressed file "Lab 1 Malware.rar" given as a project in "Lab 1 CISC 6680 Malware analysis" by professor Md Zakirul Alam Bhuiyan. As we can see from the results in Figure 9, only two engines detected the malware, which was compressed inside, and the rest didn't, and no mutexes were detected, as in Figure 10.

If the malware is not compressed, mutexes are used to avoid detection. One of them, the "TreasureHunter" (named by some strings in the code but with actual name MD5 hash 070e9a317ee53ac3814eb86bc7d5bf49) instead of going static, easily recognizable, uses a mutex value, which is dynamic and is based on the program ID of the infected Windows system. This makes it hard for malware detection systems to recognize the malicious code before it activates since the mutexes presented do not appear to be out of the ordinary. The malware is using its code to access registry locations as per example "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DigitalProductId." Then it runs a deterministic software and generated mutex values according to the Windows version and the running processions. This creates variations of the malware instead of following typical recognizable patterns.

Malware detection is done by using various software tools as "Process Hacker" and debuggers such as "OllyDbg." The malicious file created by "TreasureHunter" called "jucheck.exe" |was discovered inside the %AppData% folder. It created a mutex named 53c044b1f7eb7bc1cbf2bff088c95b30.which was identified by using the application tool “Process Hacker” and he debugger. The malware was called "DWORD PTR OS: [<KERNEL.32.CreatMutexA]" and the mutex was created.

The worrying thing is that reports from “Virustotal” and “VxStream Sandbox” showed the mutex appearing with a different MD5 values as 3ed1ed60c7d7374bf0dd76fc664b39cd or 3ac22cadc45e0558cad697d777f6c3d3. That is because the MD5 is computed using specific functions, invoking several API calls to read from the system's registry "HKLM\SOFTWARE\Microsoft\WindowsNT\Cur rentVersion\DigitalProductId the value "ADVAPI32. RegQueryValueEXW” . The specific location is where the operating system stores its Product ID. In this way, the malware code using a deterministic algorithm transformed the Product ID into the various MD5 names. That is the reason the MD5s are different. They come from a different Windows product ID.

Let's consider another example of malware mutex evasion in malware "Poison Ivy" (PIVY). The attack creates different mutexes every time to evade malware detection. In some cases, the default mutex ")! VoqA.I4" was used, but in most of the cases, the malware created a custom mutex for each attack. In a survey done by "FireEye" in multiple "Poison Ivy" reported sample cases, the malware created 148 mutexes, 56 of them were different and were used for the first time [12].

The process in which this occurred was that the malware created unique users, instead of the default "admin," as admin @338, th3bug, and menuPass, etc. and then created mutexes based on the different user names (22 different users). An in-depth investigation revealed a connection between the PIVY passwords gwx@123 and admin@338, uncovering the masquerade mutexes . They also noticed that the mutex samples taken with the use of user names gwx@123, wwwst@Admin, and admin@338 were different, but they could still identify the evasion and the masquerade because the mutexes were using a similar pattern. The PIVY process mutex and the sample count determined were:

- )!VoqA.I4 with 14 sample counts
- KADJAA#FE with 4 sample counts
- KEIVHA#$S with 3 sample counts
- %1Sjfhtd8 with 3 sample counts
- 2SF#@R@#! With 3 sample counts

The above is a clear indication of malware avoidance through mutexes, and the whole process of mutex variation creation is presented in Figure 11.

Another example of mutex evading detection that we should take a look at could be a new type of POS malware, called LogPOS. This category of POS malware is utilizing technology that is capable of evading detection by allowing the malware to inject codes, while and at the same time, it shuttles stolen credit card numbers to its C+C server.

We could say that the technology, Microsoft Windows' mailslots, is not something new to the Cybersecurity defense industry, but it is the first time a POS malware variant has been seen using it. Mailslots function as an inter-process communications mechanism which allows multiple clients to send out messages.

The applications have the possibility to store messages in a mailslot. Then, the owner of the mailslot can retrieve messages that are stored there.

According to two researchers (Jeremy Humble and Nick Hoffman), at Morphick, an Ohio-based security firm, which is the one that found the malware, LogPOS's executable creates a mailslot that acts like a server. The code that it injects into different processes acts as the client and subsequently will transfer the credit card's information to the mailslot, then quickly sends it to the C+C.

Compared to other types of POS malware like Backoff, LogPOS does not possess the capability to write the discovered data in processes, to a log file. The reason for that is because the malware already has its hands full injecting codes into processes, each of the processes searching for their own memory. None of the processes is able to open the same file with write access simultaneously, so what it does is it writes the information to a mailslot.

If we assume that the malware can create a mailslot, the malware will compare processes against a whitelist, then it injects code to disrupt processes, scans for credit card information, validates it, sends it to the mailslot and then enhances it to a remote site.

Despite all the ongoing efforts to curb POS malware from succeeding, it seems to be an area where there is no slowing down, newer POS malware variants are still emerging.

This dynamic malware evasion represents a frightening, threatening aspect, and according to reference 7, 81% of the people working in the antimalware business believe that web born malware can evade detection and remain undetectable. That is because typical antimalware systems hunt for static mutex values and thus becoming ineffective, and new dynamic mutex mutation is taking the lead.

V. CONCLUSION

Mutexes are legitimate software used by the operating system in multithreaded programs to facilitate the normal job queue process and to avoid variables having simultaneous access to a resource. The mutexes can be used by malware software to prevent infection by the same malware in different instances. This is done with the malware creating a specific mutex the moment it enters the target, so the next time the malware is injected, it uses the CreateMutex function, and in case it finds the same mutex in the system exits.

Mutexes come in two types, the unnamed ones, found only inside the process, and the named ones inside the operating system. Malware creates those mutexes in order to discover whether the victim has the same malware installed, an antivirus system operational, and, in some cases of bot creation, find other bots present and eliminate them. Only one bot malware survives.

Mutex analysis uses those mutexes to discover, classify, and fingerprint malware. The problem arises when malware uses evasion techniques to hide those mutexes. If the mutex values are not static but instead become dynamic, then it is harder (but not impossible) for the antivirus system to detect them. Typical methods of evasion and masquerade are "dynamic naming" based on the operating system's program ID and version. The evasion result is mutex creation with various MD5 values and mutex names. However across multiple malware examinations, as per the previous mentioned example, the Poison Ivy malware typical patterns of mutex names were reported in various sample counts.

Dynamic malware evasion is a frightening aspect for the antimalware society, and future malware web-borne using machine language learning will replace static mutex creation. To solve this problem, antimalware systems must evolve, too, using themselves machine learning techniques to overcome this severe problem. We should envision a future where there is a constant struggle between machine learning malware hiding their mutexes effectively by using various techniques and machine learning antivirus trying to find and eliminate them but always one step behind.

References

1 Lenny Zeltser Jul 24, 2012 "Looking at Mutex Objects for Malware Discovery & Indicators of Compromise|https://www.sans.org/blog/lo oking-at-mutex-objects-for-malware- discovery-indicators-of-compromise/

2 Lenny Zeltser Mar 9, 2015 "How Malware Generates Mutex Names to Evade Detection," https://isc.sans.edu/forums/diary/How+Ma lware+Generates+Mutex+Names+to+Eva de+Detection/19429/

3 Bmurphy, Aug 29, 2008, "What is a mutex?" https://stackoverflow.com/questions/3452 4/what-is-a-mutex

4 Aditya K. Sood, Mar 5, 2012, "Malware design strategies for circumventing detection and prevention controls," https://www.virusbulletin.com/virusbulleti n/2012/05/malware-design-strategies- circumventing-detection-and-prevention- controls-part-one

5 Paloalto Networks, Aug 14, 2014, "Hunting the Mutex," https://unit42.paloaltonetworks.com/hunti ng-mutex/

6 ExpressVPN, Jul 10, 2018, "Mixing mutex: The new malware medley?", https://www.expressvpn.com/blog/mixing -mutex-the-new- malware/?offer=3monthsfree&offer code =3c6hjoor69&gclid=Cj0KCQjwirz3BRD ARIsAImf7LP1GObqduXvaGRv3SPuGm KRs opNdD5ZibLifuqB6gY4bb4LSoi9c8 aApQPEALw wcB

7 Infosec, Jun 13, 2011, "Mutexes, part one: The Canary in the Coal Mine and Discovering New Families of Malware," https://resources.infosecinstitute.com/mute xes-analysis-part-one/#gref

8 Michael Mimoso, Mar 9, 2015, "New Technique Complicates Mutex Malware Analysis," https://threatpost.com/new- technique-complicates-mutex-malware- analysis/111517/

9 SimonGaniere.ch, Jan 2, 2015, "Mutexes and malware analysis," https://sganiere.wordpress.com/2015/01/0 2/mutexes-and-malware-analysis/

10 Mike Cohen , Jan 12, 2019, "Hunting Malware using Mutants" https://medium.com/velociraptor- ir/hunting-malware-using-mutants- ea08e86dfc19

11 Michael Sikorsky, Andrew Honig 2012, "Practical Malware Analysis: The Hands- On Guide to Dissecting Malicious Software'

12 FireEye, 2014, "POISON IVY: Assessing Damage and Extracting Intelligence," https://www.fireeye.com/blog/threat -research/2013/08/pivy-assessing- damage-and-extracting-intel.html

Figures

Abbildung in dieser Leseprobe nicht enthalten

Figure 1: Mutex resolve procedure

Abbildung in dieser Leseprobe nicht enthalten

Figure 2 Typical Mutex creation procedure

Abbildung in dieser Leseprobe nicht enthalten

Figure 3: Top Reported Malware Mutexes

Abbildung in dieser Leseprobe nicht enthalten

Figure 4: Process Hacker for system check

Abbildung in dieser Leseprobe nicht enthalten

Figure 5 Redline Data analyzer

Abbildung in dieser Leseprobe nicht enthalten

Figure 6: Object Names in the system using WinObj

Abbildung in dieser Leseprobe nicht enthalten

Figure 7: Listing of Events

Abbildung in dieser Leseprobe nicht enthalten

Figure 8: Mutexes detection on file "PracticalMalwareAnalysis-Labs.exe."

Abbildung in dieser Leseprobe nicht enthalten

Figure 9: Malware avoidance by using compression techniques

Abbildung in dieser Leseprobe nicht enthalten

Figure 10: No mutex detection by Malware analysis on compressed file Lab1 Malware.rar

Abbildung in dieser Leseprobe nicht enthalten

Figure 11: Variation of mutexes created for different users in Poison Ivy malware

[...]