During a cyber-attack adversaries might gain access to an environment through a certain system, but that might not be their actual targeted system or that might not be their end goal. To establish a permanent foothold in the environment and plan new attacks within the environment or simply continue to infect the system through reboots, adversaries need to establish persistency in that environment. There are several ways to do that and, in this article series, we will list some of the most prevalent malware persistency mechanisms.
In this entry, we will focus on utilizing Windows registry for malware persistency.
Windows Registry
Windows registry is utilized by the system to store and retrieve system and user settings. However, malware authors can exploit this utility to ensure persistency for the malicious software by inserting values into registries that are automatically executed on startup.
Here are some typical locations for autoruns:
DAT\Software\Microsoft\ Windows\CurrentVersion\RunHKCU\Software\Wow6432Node\Microsoft\WindowsNT\CurrentVersion\WindowsHKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce\*HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run\*HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce\*HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run\*
If you are interested to see it yourself on your own system, you can download Autoruns from Microsoft and see something like the below.
Figure 1 – Autoruns example
And here is a simple example of how one would create such persistency with C++:
Figure 2 – Malware persistency example with C++
When analyzing malware samples, you might discover usages of WinAPI function that interact with registry. As shown in the above screenshot of the code, these may be used to gain persistence in the victim’s environment.
Detecting Windows registry persistency
Since this persistency method relies on modifying some typical and known registry keys, we could leverage our EDR (Endpoint Detection and Response) tool to detect any suspicious changes to registries. Especially the ones that we listed at the beginning of this article. A lot of EDR tools will have such detection rules already built-in. However, it will be the analyst’s job to determine whether this modification of registry is indeed malicious.
The best way to determine this is by either observing the parent process of the command that initiated the registry change. In this case, one could detect a suspicious executable, perhaps unsigned executable, unexpected file path, bad reputation, etc. This would give them a reason to report this as a potential intrusion.
One other way would be to inspect the actual registry modification. In our simple case, you can see that we were quite open with our registry name (“malicious”) and our malware executable name is “bad.exe”. This probably won’t be the case in real life scenarios, but some values might still give it out as a suspicious change.
