Introduction
Just like in magic tricks, a malware infection very often consists of three parts or acts. Paraphrasing the following narration from the film “The Prestige (2006)” gives an idea of what we are going to talk about.
“Every malware infection consists of three parts or acts. The first part is called the pledge; the attacker shows you something ordinary, like a document or a web page. The second act is called the turn; the attacker takes that ordinary something and makes it into something extraordinary. But you wouldn’t clap yet, because making something disappear isn’t enough. You have to bring it BACK.”
In this case, bringing this something back is not something the attackers want you to see, and they definitely won’t be offended if you don’t clap. This is what the prestige in malware persistence is all about.
The case study
During recent malware analysis engagements, we came across an interesting persistence mechanism which proves to be quite effective.
The malware itself is built as a DLL file and uses the common technique of loading itself by adding a registry key that launches rundll32.exe and loads the malicious DLL which is dropped in “C:Users<username>AppdataRoaming” directory. The DLL file uses a random name using the regex pattern: ^[0-9A-F]{3,4}.tmp$, for example: “1FD9.tmp”.
However, what happens next is the interesting part of this case study. Every time we start the system, the malicious DLL will subsequently inject itself in explorer.exe and then delete its persistence traces, including itself and the aforementioned key in Windows registry.
During analysis, we noticed that the malware was also injecting itself to the Windows ‘Desktop Window Manager’ process (dwm.exe). Both of the infected processes are normally running in the security context of the current user.
During shutdown, the malware will place back itself and the registry key used as a persistence mechanism to load itself after every reboot of the infected host.
Are you looking closely?
Any attempts to look for common persistence indicators using ordinary tools, such as the well-known ‘autoruns’ utility from the Sysinternals, will fail in this case. This is for the simple reason that while the malware is active it deletes its traces.
However, by examining the virtual address space of Windows Explorer with VMMap from Sysinternals, we can retrieve some interesting clues (figure 1).
Figure 1- Mapped Memory with RWE permissions
If we look closer at the first one in this case, we can find another very important clue that indicates that something might be wrong in this host (figure 2).
Figure 2- Prestige in Malware Presistence
We can clearly see an absolute path to a file, but browsing to that directory or attempting to find a registry key that contains any data pointing to that will not return anything useful to us.
A good old trick
Restarting the host in safe mode will not allow for the malware to load and delete its traces (figures 3, 4).
Figure 3- The malicious DLL file
Figure 4- The registry key used for persistence
Also note that the malware changes its own filename every time it executes.
Going one step further
So far we have found significant details regarding the hiding and the persistence mechanisms of this malware, but we still haven’t shown a proof of what we have been discussing so far.
Debugging Windows explorer locally on shutdown to catch the event of the malware that writes itself back won’t help us much, since the OS will also kill the debugger process before we manage to see anything useful.
However, by enabling auditing in that directory for successful events related to the creation and writing data to files, we can then go back and examine the logs (figure 5).
Figure 5- Event logs
We can clearly see that indeed it was the Windows explorer process that dropped the malicious DLL file back to its place.
Conclusion
During malware analysis we see all sorts of tricks and tactics for evading detection. This particular case was really interesting because the malware was very effective at hiding from common auditing tools that report auto-run registry keys as potential indicators of compromise. Furthermore, it was achieved without using any high or low system level hooks that are harder to implement and which also add a fair portion of artefacts into the system.
To contact Nettitude editor, please email media@nettitude.com.
