Resources Used for Persistence

All operating systems, including Windows, have provisions to start certain processes automatically when the system boots up or when the user logs in. Linux has init files as one such mechanism, while Windows has various other mechanisms, such as registry keys, startup folders, services, and so forth, also known as autostart extensibility points (ASEP). These mechanisms are used by various benign services and software that autostart on bootup to set up the user’s system and to provide a better user experience. This also allows users to enable software they need to automatically start when they log in.

But malware also makes use of these very same autostart techniques so that they can persist across reboots and system shutdowns. For example, malware can make a startup registry entry pointing to its file path on disk or place a copy of itself into the startup folders, so that when the system boots, the OS automatically starts the malware.

The persistence mechanism used by malware also depends on the type and the purpose of the malware. For example, a malware PE file can either be an executable or a DLL file or even a kernel module. Malware that tries to steal data from your browser needs to be coded as a browser module, which is loaded as a plugin when the browser starts. Persistence, in this case, requires the malware to register itself as a browser plugin. Alternatively, if it is a binary executable, it can make an entry in one of the run registry keys or place the executable in one of the startup folders.

Before we can investigate persistence mechanisms, let’s first run through the two tools—Autoruns and ProcMon, which are very useful in detecting persistence mechanisms as we dynamically analyze malware samples.

Analysis Tools

We now introduce you to two very important tools: ProcMon and Autoruns. ProcMon is very important during the analysis process. We use these tools throughout this book to analyze malware samples. We recommended you to thoroughly play with these tools with our various hands-on exercises in this chapter and throughout the book.

Autoruns

Autoruns is a tool that scans the system and lists all the programs and services making use of any kind of autostart persistence mechanism. This is a very valuable tool that one can use while analyzing samples and complements other tools like APIMiner and Sandboxes that also helps us identify some of the persistence mechanisms used by malware.

As an exercise, run Autoruns on your analysis VM using the baseline snapshot established in Chapter 2. It might take a while for the tool to finish a full scan and list all the entries. Figure 8-1 shows that the Everything tab lists multiple programs and services using a persistence mechanism.

Autoruns has multiple tabs at the top that segregates and lists the software and services based on the type of persistence mechanism that is being used. For example, the Logon tab lists the software that persists/autostarts when a user logs into the system. The Services tab lists all the services that are registered on the system. Do note that Autoruns hides entries for software that belong to Microsoft/Windows by default. To view all entries, including signed Microsoft software, you can go to Options and deselect Hide Windows Entries. We recommend you to take your time and get comfortable with the interface and go through the various tabs and roughly go through the various entries Autoruns shows.

ProcMon

ProcMon is an important tool used in malware analysis that is logs various events occurring on the system. Using ProcMon, the following are some of the important events related to malware analysis that you can capture.

• Process creation and shutdown

• Thread creation and shutdown

• File creation and deletions

• Registry entry creations, deletions, and modifications

• Network activity

The power of ProcMon comes from the fact that it logs these events for all processes running on the system, logging important supporting meta information like the time, process name, and PID that generated an event. ProcMon also provides advanced filters that let you filter and only view events matching specific type, PID, TID, and other meta-information related to the event. Figure 8-2 shows an image of ProcMon in action.

As you can see, ProcMon provides four quick access buttons that let you filter events based on the different high-level categories of events: registry, file, network, process and threads, and profiling events. ProcMon also provides two shortcut buttons (as seen in Figure 8-2) that let you start/stop event capture, and another button to Clear the Events. These two buttons can also be accessed via keyboard shortcuts CTRL+E and CTRL+X, respectively.

While analyzing malware samples with ProcMon, you can stop the capture of events and clear the events. But just before you execute the malware sample, you can start the capture of events. Once the sample has run, you can stop the capture of events; otherwise, you’d have far too many events, and the ProcMon UI can lag when dealing with a deluge of events.

ProcMon has a lot more features, including some very important ones that let you filter(exclude/include) events based on various event metainformation. You must get comfortable with this tool. We suggest you go through the resource links we have specified in the file Procmon-Guide.txt in our samples repo that covers in detail the various other aspects of this tool and gets your hands dirty with its various features.

In the next set of sections, we go through the various persistence mechanisms in detail. All the sections are very hands-on with corresponding images and step-by-step guides, including ones that cover how to use analysis tools. We recommend you to try out the exercises in the sections as and when you are reading through the section. It won’t be possible for us to add pictures and steps for every mechanism, but as an exercise, you should try out all the various mechanisms using the procedures that we provide for some of the common ones.

Startup Shell Directories

As an exercise open regedit.exe and verify if the Startup value under the keys in Table 8-1 match the paths specified in Listing 8-1, as seen in Figure 8-3.

Let’s use Sample-8-1. Add the .exe extension to this sample. Now type shell: common startup as the first command in the RUN window, as shown in Figure 8-4.

This should open the startup folder C:ProgramDataMicrosoftWindowsStartMenuProgramsStartUp. Now copy Sample-8-1.exe into this folder, as shown in Figure 8-5.

Now restart the system and login back into the system. As you can see in Figure 8-6, the OS has automatically launched Sample-8-1.exe as a process.

Now let’s verify if Autoruns detects the presence of this program in any of the autostart mechanisms. You can now run Autoruns. (Autoruns takes time to completely scan and return the results of its search.) As seen in Figure 8-7, Autoruns has indeed detected the persistence for Sample-8-1.exe.

Next, filter the events in ProcMon by using the event filter buttons at the top of ProcMon, which we showed in Figure 8-2. You only want to see the file system activity. So you can deselect the other buttons while enabling the Show File System Activity button. After this filtration, the number of events is drastically reduced, showing you all the file related events that occurred on the system. You can scroll through the events to find an event that shows Sample-8-1.exe being copied to the startup folder, as seen in Figure 8-8.

Also, note the process name and PID of the process that generated this event. While you are analyzing malware, you have to note the events that are generated by the malware process or any of the child processes that it created or any other process that it might have injected itself into using code injection (covered in Chapter 10).

As an exercise, you can now repeat all the steps using Autoruns and ProcMon for the same sample Sample-8-1.exe but for the other startup folder accessible using the shell:startup shortcut. We recommend that you play around and exercise as much as possible, as these steps are very fundamental to the malware analysis process.

Registry RUN

The Windows Registry is a database of configurations and settings, many of which are used by the OS for system setup during bootup. The Windows OS also provides registry keys, also called RUN entries that can autostart programs on system startup. Clean software creates these RUN entries so that they are autostarted when the system starts up, a good example being antivirus software. Malware similarly creates RUN entries so they can persist across system boots, and the system autostarts them when it boots up. The RUN entry is the technique more commonly used by malware to persist on the system.

Let’s now run the same exercise we ran in the previous section. Let’s create a RUN autostart entry for Sample-8-1.exe at HKLMSoftwareMicrosoftWindowsCurrentVersionRun by adding a new value of type String Value, as seen in Figure 8-9. Do note that you will have to add the full path to the Sample-8-1.exe as the value.

Now run Autoruns as you did in the previous section. As before, it shows you that Sample-8-1.exe has been added to the OS autostart under the RUN key in the registry. The great thing about Autoruns is that it also shows you the exact autostart mechanism used and also the RUN key name under which the value has been entered, as seen in Figure 8-10.

Now restart the system and login back into the system. Notice that Sample-8-1.exe has been automatically launched as a process, similar to Figure 8-6.

Next, filter the events in ProcMon by using the event filter buttons at the top of ProcMon, which we showed in Figure 8-2. You only want to see the registry activity. So you can deselect the other buttons while enabling the Show Registry Activity button. After this filtration, the number of events is drastically reduced, showing you all the registry related events that occurred on the system. You can scroll through the events to find an event that shows a RUN entry being created for Sample-8-1.exe, as seen in Figure 8-11.

You can obtain the value, the file path in this case, that was added by either hovering your mouse over the event or by double-clicking the event in ProcMon, which should open a Properties window for the event as seen in Figure 8-12.

As an exercise, you can now repeat all the steps using Autoruns and ProcMon for Sample-8-1.exe. Try to memorize the RUN keys so that you can easily identify them when scrolling through the event logs in ProcMon during malware analysis.

Services

Windows services is a widely used technique by malware. One of the top advantages that malware gains by registering as a service is the autostart mechanism it provides. Windows services can be registered to automatically be started by the OS on system startup. It also provides resilience against crashes by restarting the service if it exits or crashes, which is a bonus.

You can read about the various techniques that malware use to register itself as service in the “Windows Services” and “Malware as Windows Services” sections.

But let’s re-run the exercise from the and “Malware as Windows Services” section in Chapter 5 using Sample-5-1. Repeat the steps for the exercise from the section using the commands from Figure 5-21, which registers and starts a service. You can now open the Autoruns tool that shows that a persistence mechanism has been created for Sample-5-1 using a service, as seen in Figure 8-13.

Now restart the machine and log back in. Open ProcessHacker, and you notice that Sample-5-1.exe has been started as a process under services.exe as the parent process, thereby showing us the success of this persistence mechanism.

Now filter the events in ProcMon by using the event filter buttons at the top of ProcMon, which we showed in Figure 8-2. You only want to see Registry Activity. So you can deselect the other buttons while enabling the Show Registry Activity button. You can scroll through the events to find an event that shows a new key created by services.exe at the path HKLMSYSTEMCurrentControlSetservicesBookServiceImagePath as seen in Figure 8-14. You might remember that HKLMSYSTEMCurrentControlSetservices is one of the paths where newly created services are entered into the registry. If you see a RegSetValue event in ProcMon for the path in the sample process that you are analyzing, it is suspicious and warrants further investigation.

You can double-click this event row in ProcMon to obtain the various properties of this event, including the value under this key, as seen in Figure 8-15, which is the path to our new service executable Service-5-1.exe.

Similarly, you only want to filter Process Activity. So you can deselect the other buttons while enabling the Show Process Activity button. As seen in Figure 8-16, you can scroll through the events to find an event that shows a new process sc.exe created, which was the command we used earlier to register our BookService service.

Double-clicking this event shows you the full command line used for registering our service, as seen in Figure 8-17.

File Infection

Executable files can be used as persistence mechanisms using a technique called file infection . The malware that uses this technique is also called a file infector or a virus. Viruses infect healthy files on the system and alter the code of the host executable by adding their malicious code into the file. When the infected host executable file starts as a process, it automatically starts the malware or malicious code that is now inserted within it. When a virus infection strikes, it infects every executable on the system.

Identifying this technique is easily done with dynamic analysis. To detect if malware is using this technique, one can check if the sample is making any modifications to executable files on the system. A stronger indicator is if the target files which the sample is modifying are system files located in the system32 folder, since these files shouldn’t be altered by nonsystem processes. ProcMon is the ideal tool for this detection task because it shows you all the file-related activity, including modifications to any file on the disk.

DLL Hijacking

In Chapter 4, you learned that executable files depend on DLL files to function. This includes a dependency on the system-provided DLLs and third-party DLLs. Most executable on Windows needs some well-known system provided DLLs to execute like msvcrt.dll, advap32.dll, and so forth. When an executable has a dependency on any DLL, the Windows loader needs to find and load them into the process’s memory as it is staring the process. But how does the Windows loader know where on the disk these DLLs are located?

Malware is known to misuse this feature of the Windows loader to run using a method known as DLL hijacking, also known as DLL search order hijacking. The malware places a malicious DLL file in a search order directory where the actual clean DLL is located. For example, consider a case where Adobe Acrobat PDF Reader has a dependency on advapi32.dll, which is a system DLL located in C:windowssystem32. To persist, the malware DLL can rename a malicious payload of it as advapi32.dll and place it in the same folder as the Adobe Acrobat PDF Reader executable file. Now since the directory of the executable file is searched first before the system32 folder, the Windows loader loads the malicious advapi32.dll instead of the clean one located in the system32 folder, thereby loading the malware DLL into the clean process.

Winlogon

The Winlogon.exe process is responsible for taking care of the user logging in to the system. It is responsible for starting processes that the user needs after logon. These programs that are started by WinLogon are placed under the registry key HKLMSoftwareMicrosoftWindowsNTCurrentVersionWinlogon. The names under this KEY that hold the programs that WinLogon starts are Userinit, Shell, and Notify, as seen in Figure 8-18.

The Shell entry holds the value of Explorer.exe by default. It is the Windows File Explorer that we fondly use to browse the folders and files on our system. Malware can modify the value of this entry to add malicious executables of its own that that starts on system startup.

The Userinit value similarly can be modified by malware by adding the path to their malicious executables, that is autostarted on system startup. The paths to the programs in this value should be comma-separated with a trailing comma at the end of the value.

Task Scheduler

Similar to the cron jobs facility in Linux, the Windows Task Scheduler is a feature provided by Windows OS that allows one to schedule the launch of programs and software at fixed times or fixed intervals. Many malware, including the notorious Shamoon malware family, are known to use this mechanism to persist on the system by scheduling tasks that run them.

This command has scheduled a calculator to run every minute from 10:15 PM onward. You can verify the creation of the scheduled task by opening the Task Scheduler tool provided by Microsoft and available natively on Windows OS, as seen in Figure 8-19.

While analyzing samples, we can detect malware that uses this technique very similar to how we did for services, by using a combination of ProcMon and Autoruns. Using ProcMon, you should be able to catch a Process Event by the process SchTasks along with the command line from the command you ran in Listing 8-3. We leave this as an exercise for you to try.

Debuggers

To facilitate software developers to debug applications, Microsoft provides various options in the registry that allows one to open an application under the control of a debugger. Let’s go through some of these options made available by Microsoft.

Image File Execution Option (IFEO)

IFEO is a popular debugging facility made available on Windows as a key at HKLMSOFTWAREMicrosoftWindowsNTCurrentVersionImage file execution options. To use this facility, you need to add a value to the application key they want to debug at the registry key location.

As an exercise, open the registry key location. In most cases, you should have a subkey called iexplore.exe at the key. If not, you can create a new subkey called iexplore.exe. Now let’s create a string value for the iexplore.exe key located under Image File Execution Options. You can do this by right-clicking the iexplore.exe key ➤ New ➤ String Value. Then set a new name-value, where the name is Debugger, and its value is C:windowssystem32calc.exe, which is the Calculator application. Figure 8-20 shows how it looks after setting this value. This sets up our application iexplore.exe or rather the Internet Explorer browser to be debugged by calc.exe.

You can now verify this by opening Internet Explorer, which would end up starting the Calculator(calc.exe) program instead, as we specified in the registry.

Malware often uses the same facility to persist themselves, by setting themselves as the debugger to various applications. As an analyst to catch this mechanism while analyzing samples, you can use ProcMon and AutoRuns. As an exercise, you can reset your VM to try the steps, and use ProcMon and Autoruns to identify this mechanism.

SilentProcessExit

There are other options that launch executables. You saw that by using IFEO, you could launch the calc.exe executable when we tried to launch iexplore.exe. Similarly, we can have Windows launch programs when other processes exit.

One option is SilentProcessExit, which uses registry key entries at both HKLMSOFTWAREMicrosoftWindowsNTCurrentVersionSilentProcessExit and HKLMSOFTWAREMicrosoftWindowsNTCurrentVersionImage file execution options to achieve this.

As an exercise, you can set Notepad.exe application to be launched when Internet Explorer (iexplore.exe) exits. To do this, we need to set registry values for both keys. Instead of using the graphical editor, we can set the same values using the reg command from the command prompt. Run the three commands in Listing 8-4. Alternatively, if you are comfortable with the registry editor, you can manually set these values.

reg add "HKLMSOFTWAREMicrosoftWindows NTCurrentVersionImage File Execution Optionsiexplore.exe" /v GlobalFlag /t REG_DWORD /d 512

reg add "HKLMSOFTWAREMicrosoftWindows NTCurrentVersionSilentProcessExitiexplore.exe" /v ReportingMode /t REG_DWORD /d 1

reg add "HKLMSOFTWAREMicrosoftWindows NTCurrentVersionSilentProcessExitiexplore.exe" /v MonitorProcess /d "C:windowssystem32 otepad.exe"

Listing 8-4

Setting Registry Values That Autostarts Notepad When Internet Explorer Exits

After running these commands, your registry keys/values should look the same as in Figure 8-21.

Very similar to what we did in the previous section, we can catch this persistence mechanism by using Autoruns and ProcMon. As an exercise, you can use these tools to detect this mechanism while you set these registry keys.

In addition to IFEO, there are other options to set debuggers. The following lists some of them.

• HKLMSOFTWAREMicrosoft.NETFrameworkDbgManagedDebugger

• HKLMSOFTWAREMicrosoftWindows NTCurrentVersionAeDebugDebugger

Summary

Persistence is a very important feature that is widely used by malware so that they can survive system reboots and shutdowns. We covered various well-known persistence mechanisms that malware uses to persist itself, including registry RUN, startup folders, services, scheduled tasks, debuggers—all of which various malware have used to enable persistence. You also learned how to use two new dynamic analysis tools—Autoruns and ProcMon. We were able to catch these various persistence mechanisms using hands-on exercises.