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 ones malware persistency mechanisms.
In this entry we will focus on utilizing Windows registry for malware persistency.
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 startups.
Here are some typical locations for autoruns:
If you are interested to see it by yourself on your own system, you can download Autoruns from Microsoft, to see something like 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 persistency in 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 begining of this article. A lot of EDR tools will have such detection rules already built-in. However, it will be analyst’s job to determine whether this modifications of registry are 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 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 live scenarios, but some values might still give it out as a suspicious change.