Once executed on target system, a malware try to hide itself and achieving persistence on the exploited machine, in order to continue to act even after system reboot.
Today let’s try to focus on Windows systems, which have a lot of areas through which the persistence can be achieved.
The Windows Registry
As I stated above windows has a lot of AutoStart Extension Points(ASEP). When it comes to malware, most of them would like to achieve persistence by editing the below registry keys at User Level:
If the malware gains admin privileges, it can edit some keys at admin/system level privileges:
Jerry Cooke, in the comments, correctly suggest another location:
As other locations where malware might persistently start from.
I spent ages looking for where malware was starting from when doing a training course for incident response before realising that location existed for 64-bit apps.
Since smss.exe launches before windows subsystem loads, it calls configuration subsystem to load the hive present at
Also smss.exe will launch anything present in the BootExecute key at
It should always have the value of autocheck autochk*. If there are more values in it, then probably the malware is likely to launch at boot.
Winlogon process uses the value specified in the Userinit key to launch login scripts etc.
This key is location at
Usually, userinit key points to userinit.exe but if this key can be altered, then that exe will also launch by Winlogon.
Since Winlogon handles Secure Attention Sequence (SAS) (Ctrl+Alt+Del), notify subkeys found at
are used to notify event handles when SAS happens and loads a DLL. This DLL can be edited to launch whenever such SAS event occurs.
Pointed by key located at
this key points to explorer.exe and should only be string explorer.exe rather than complete path as it is supposed to launch from windows.
The boot key at
points to the location under Winlogon only.
Placing a malicious file under the startup directory is often used by malware authors.
Any shortcut created to the location pointed by subkey Startup will launch the service during logon/reboot.
Start up location is specified both at Local Machine and Current User.
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
Many windows services are required to run at boot like Workstation/server services, Windows Event Log, and other Win drivers. These are located at
Along with placing a malicious file in the above-listed registry key, there is another way to load malicious files. Malicious files can be loaded if a service fails to start.
There are some other keys which are used to start background services like remote registry service. These are located at:
Browser Helper Objects
It is essentially a DLL module loaded when Internet Explorer starts up. Various data theft types malware affect Browser Helper Objects.
They are located at
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects
There are various subkeys under BHO which tell the browser to load which DLLs.
Key located at
will show the DLLs loaded by the User32.dll.
As most executables load User32.dll, this is a good place for malicious DLLs to reside.
There are various keys which are used to specify the action when a certain type of files are open, located at
DLL Search Order Hijacking
Another common method used by malware is to hijack a concept about how the OS loads DLLs. Whenever an exe loads (even explorer.exe), it follows a certain path search to load the required DLLs.
Because DLLs are loaded in the order the directories are parsed, it is possible to add a malicious DLL with the same name in a directory earlier than the directory where the legit DLL resides.
If Safe DLL search mode is enabled (which is by default on most versions) then OS will check whether the DLL is already loaded in memory or is it a part of Known DLLs registry key located at
If OS cannot find the DLL at either of these, then DLL search starts in the following order
- Directory from where application was launched
- System Directory(WindowsSystem32)
- Windows Directory
- Current Working Directory
- Directories defined in the PATH variable.
So a malware can easily place a malicious DLL in the search order.
More information can be found here
Simple but very effective technique: hijack the shortcut icons Target attribute. Along with a normal application to be launched, shortcut icon can be forced to download content from an evil site.
Note that there are various other methods like infecting MBR, COM object hijack, etc. are also by malware, but above are some of the common method used by malware to achieve persistence.
A bootkit is a malware variant that modifies the boot sectors of a hard drive, including the Master Boot Record (MBR) and Volume Boot Record (VBR).
Malicious programs may use bootkits to persist on systems at a layer below the operating system, which may make it difficult to perform full remediation unless an organization suspects one was used and can act accordingly.
Master Boot Record
The MBR is the section of disk that is first loaded after completing hardware initialization by the BIOS. It is the location of the boot loader. An adversary who has raw access to the boot drive may overwrite this area, diverting execution during startup from the normal boot loader to adversary code.
Volume Boot Record
The MBR passes control of the boot process to the VBR. Similar to the case of MBR, an adversary who has raw access to the boot drive may overwrite the VBR to divert execution during startup to adversary code.
The Microsoft Component Object Model (COM) is a system within Windows to enable interaction between software components through the operating system.
Malware can use this system to insert malicious code that can be executed in place of legitimate software through hijacking the COM references and relationships as a means for persistence.
Hijacking a COM object requires a change in the Windows Registry to replace a reference to a legitimate system component which may cause that component to not work when executed.
When that system component is executed through normal system operation the adversary’s code will be executed instead.