Background Activity Moderator
The Background Activity Moderator is a Windows service used to control the activities of background applications. This service was initially introduced in Windows 10. BAM provides the full path of executables running on the system along with the last execution date and time of these files.
BAM provides evidence of program execution by listing the following executables:
HKLM\SYSTEM\ControlSet00X\Services\bam\State\UserSettings\SID\
(where X is typically “1”) registry key. Each user-specific executable is stored under the corresponding user’s SID entry. BAM entries only populate for executables run locally. Entries older than 7 days are removed when Windows starts.
Here we can see different user SIDs. BAM artifacts provide us with more detailed execution evidence because they distinguish which application was executed by which user, whereas other execution evidence artifacts (like prefetch) only provide overall execution on the system.
The full path of executables running in the background and the timestamps of their execution can be obtained. However, executables launched on network shares or removable media do not generate BAM entries. Similarly, console applications are not stored in BAM entries. If an executable is deleted from its original location, the BAM entry is also removed.
Therefore, this artifact has its limitations for forensic purposes.
Services and Startup Persistence
Attackers may create or modify Windows services to repeatedly execute malicious payloads, achieving persistence. When Windows starts, it launches programs or applications (referred to as services) that perform background system functions. Windows service configuration information, including the file path of the service executable or recovery programs/commands, is stored in the Windows Registry.
Attackers may install new services or modify existing ones to execute at startup, thereby maintaining persistence in the system. Services can be set up or modified using system utilities (such as sc.exe), directly modifying the registry, or directly interacting with the Windows API.
sc create test binpath="cmd.exe /k C:\Windows\System32\calc.exe" start="auto" obj="LocalSystem" sc qc test
We simulate creating a malicious Windows service using the built-in tool command line named “sc.exe”. Suppose we register the system calculator’s binary file as a Windows service to achieve persistence. We do this using the following command:
How to detect this technique? There is a registry location that holds information about system-wide services, the path is:
SYSTEM\ControlSet00x\Services
where x gets a numeric value based on the service but is typically “1”. Open the SYSTEM Hive in the registry explorer to view.
There are many services here, which are expected services of Windows OS activities.
So how do we find the service we want? For quick analysis, prioritize searching for all services with .exe files under any user folder. Since most Windows services run from the system root directory, we are more likely to find malicious services with .exe files in the user directory.
This does not mean that attackers cannot create services with .exe files in the system root directory; they can also do this to obfuscate. For example, in my example above, I used a file from the system as a service, so it is not absolute.
Next is startup execution persistence. Startup is a feature of Windows that allows applications and programs to execute automatically when the computer restarts. These programs can be configured in the registry through the Run keys. The paths to these keys are:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
Here we placed a calculator in the current user’s document directory and added it to startup, then analyzed the registry to detect it.
reg add "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run" /v Zgao_RunKey /t REG_SZ /d "C:\Users\Administrator\Documents\calc.exe"
Open the registry explorer and load NTUSER.dat.
Here we can see the newly added exe file. Attackers can also name it as Windows Service, OneDrive Service, or any name similar to other legitimate software used in the environment to blend in. The key focus is on the “Data” field containing the executable file path.
USB and External Connected Devices
Universal Serial Bus flash drives (commonly known as USB flash drives) are the most common storage devices that can serve as evidence in digital forensic investigations. The use of USB and external drives in the workplace may allow insider threats to steal sensitive or confidential company data or information from the system without authorization. Forensic examination of USBs is crucial for investigating and resolving such cases.
The first registry path is the USBSTOR key, which only holds information about external storage media/drives (such as USBs, hard drives, etc.), located at:
HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR HKLM\SYSTEM\CurrentControlSet\Enum\USB
We can see that this USB device is branded as SanDisk.
We see detailed information about the device in the selected key.
The second key provides information about all devices connected via USB, such as keyboards, mice, microphones, etc.
By examining this registry key, we can understand the type of devices and the last time they were connected to the system. Clicking on the USBSTOR key itself provides summary information about all devices under it.
Remote Desktop Connection
Microsoft Remote Desktop Connection (RDC) allows users to connect and access other Windows systems over a network. It is a built-in application that uses Terminal Services or Remote Desktop Services to implement the Remote Desktop Protocol (RDP) to access and control all applications, files, and network resources on a remote system.
RDC is typically used by system administrators to perform administrative tasks, such as configuring computers and troubleshooting computer and network issues. However, attackers can also use it to perform malicious activities on remote Windows systems. Therefore, Remote Desktop Connection MRU artifacts are crucial for determining which systems the attacker accessed.
This artifact is stored in the registry at the following path:
NTUSER.DAT\Software\Microsoft\Terminal Server Client
The values under this key start with “MRU” followed by a numeric value. The number indicates the order in which these systems were accessed. Each new connection is assigned the value “MRU0,” and the numbers of all other values will increase sequentially. The data associated with the MRU values can contain the names or IP addresses of the systems accessed by the user.
This information is very important; sometimes attackers clear the event logs, and we cannot obtain any other information about RDP activities from the event logs. If the target remote device is connected using a hostname instead of an IP, this registry key will also save the hostname (which will also be recorded). Another advantage of the list of RDP-connected devices is that they are sorted by default from the most recent to the oldest.