A quick journey in the System32
Table of Contents
System32 is the standard Windows system library directory located in C:\Windows\System32.
It’s one of the first directories hackers will target in Windows. Likewise, investigators and security professionals will likely look into this big folder to find artifacts and other IoCs (Indicators of Compromise).
Roughly speaking, it contains critical files and programs for the system, but also configuration files, system logs, and other settings to connect devices.
There are literally hundreds of files in various formats such as
.dat (data files), or DLL (Dynamic Link Libraries). Many of them are locked by the system itself. It does not mean you can’t delete them, but a user (even with privileges) cannot simply right click and trash those files.
If such bad situation eventually happens, you will likely get a blue screen, inviting you to repair the system.
You might already know files like
cmd.exe (command prompt) or advanced commands provided by Powershell. Everything points more or less to System32.
Attackers often target DLL files in Windows systems with known attacks such as DLL hijacking. Because many Windows applications load these libraries automatically on startup without specific instructions, a classic technique consists of replacing a legitimate DLL with an evil one to escalate privileges and/or perform malicious actions.
DLL can have different extensions like
.dll but also
.drv. Some applications may have additional security checks, but more sophisticated attacks can mimic signatures and fool detection (e.g., the Solarwinds disaster).
Windows separate 32 and 64-bit programs (and associated files) in two different directories. It’s necessary because you need different DLL in each case. Otherwise, the system can crash. You’ll find this separation in various Windows directories, like System32 but also C:\Program Files.
It’s a fully automated process that runs in the background, but it’s still possible to add DLL files manually like attackers or players who crack video games do.
It gets a bit more complicated with “WoW64,” as Windows allows 32-bit programs to run on 64-bit versions without additional modifications. Behind the scene, the system applies some redirections, like pointing C:\Program Files at (x86), to ensure everything works correctly.
Microsoft did it for retro-compatibility purposes, as renaming such critical folders may have broke the entire World (as Windows is everywhere), but it’s a kind of messy, as System32 is 64-bit while SysWOW64 is 32-bit. WoW ^^!
Forensics and malware analysis can start by exploring and monitoring processes to find active files in use and possibly catch any foreign DLL that is not supposed to run, or that is loaded from a suspicious path.
Then, it’s not uncommon for security professionals to upload such DLL directly on popular databases like VirusTotal to determine whether it matches a known malware.
In an isolated and secured environment, it’s also possible to run the malware to see what it does, especially to the Windows Registry. Registry files are located C:\Windows\System32\Config and contain keys and associated values that control critical functions. For example, UAC (User Account Control) can be deactivated by modifying the value of a specific key in the Windows Registry.
The investigator can take snapshots of the Registry before and after running a suspicious executable, using free open-source utilities like Regshot, to compare entries and generate a diff.
It should be noted there’s a specific key in the Registry that holds the KnownDLL directory, which contains known systems DLL:
An attacker can modify it. Indeed, there are various types of DLL hijacking, and the outcome depends on developers’ practices (e.g., secure loads from specific paths, SafeDllSearchMode).
These attacks usually exploit the DLL search order.
The “modern” trend for attackers is called LOTL (“living off the land”) and consists of leveraging existing system utilities or Powershell commands to hide activities.
Indeed, Windows won’t flag its own utilities and processes, but it’s still possible for an attacker to modify the execution policy, schedule malicious tasks, or exfiltrate data. This stealthier approach allows evading most classic detection tools, as signature-based verification won’t catch it.
In addition, system tools are usually whitelisted by security solutions.
Defenders may use behavioral analysis to restrict applications and processes according to their actions, and not a simple signature. Volatility is also indicated if you have an image file to analyze (see documentation).
The tool can reveal which commands are executed by seemingly harmless binaries:
csrss.exe pid: 606
Command line : C:\WINDOWS\system32\csrss.exe […]
N.B: 606 is an arbitrary PID here
Of course, the Windows System32 folder is not the only area you should inspect after an attack, but you can’t skip it.
As a user or a beginner in investigations, never remove or quarantine files in this critical folder without analyzing them before, even if the names look suspicious. For example, some “tutorials” explain that “csrss.exe” is a virus you have to delete at all costs while it’s a core file, at least in Windows 10 or 8. It’s just that attackers can attempt to divert it (or replace it).
However, the system becomes unstable without its core components, and you won’t know what happened. So, take snapshots and create system images you can analyze with the proper tools in a dedicated environment.