Suspicious Windows DLLs: Detection, Hijacking, and Defense

In recent years, Suspicious Windows DLLs have become one of attackers' favorite vectorsWe are not just talking about malware not just classic EXE format programs, but seemingly legitimate libraries that infiltrate trusted processes, camouflage themselves among system files, and fly under the radar of many security solutions.

This boom is no coincidence: techniques such as DLL hijacking, side-loading, or DLL injection They exploit precisely how Windows searches for, loads, and reuses these shared libraries. Add to this the emergence of artificial intelligence engines capable of both detecting and concealing these types of threats, and we have a scenario where defenders and attackers coexist, employing increasingly sophisticated strategies.

What is a DLL and why is it so lucrative for attackers?

On Windows, a DLL (Dynamic Link Library) is a file that contains executable code, functions, and reusable resources. by multiple programs simultaneously. Its role is similar to that of .so libraries in systems Unix: allows multiple applications to share the same functionality without duplicating code, saving memory and disk space.

DLLs usually end with the extension . .dll, although they can also be presented as .drv or other executable formatsAnd some EXEs can even function, in practice, as containers for similar functionalities. The end user doesn't open them directly: the system itself or the applications load them when needed, usually at startup or during execution.

The direct consequence is that A single DLL can be used by multiple programs at the same timeIf an attacker manages to manipulate or infect one of these libraries with malicious code, the impact will be multiplied: several trusted processes could be running the same compromised library without raising any obvious suspicion.

Within Windows there are dozens of DLLs critical to the system's operationMany of these are common targets in malware analysis and code injection or obfuscation techniques. Some of the most relevant are:

• KERNEL32.dll: manages memory, files, process creation and access to hardware.
• Advapi32.dll: includes advanced functions related to service registration and administration.
• User32.dll: handles the graphical interface, buttons, scroll bars, and user events.
• Gdi32.dll: deals with displaying and manipulating graphic elements on screen.
• ntdll.dll: acts as an interface with the Windows kernel; it is usually imported indirectly through KERNEL32.dll.
• WSock32.dll and Ws2_32.dllThey provide basic network functionality (sockets, communications).
• Wininet.dll: implements high-level network functions (HTTP, FTP, NTP).

When an executable imports directly Ntdll.dll to perform undocumented or low-level operationsOften, this is a clue that special capabilities are being sought, such as hiding processes, evading security controls, or manipulating the system more aggressively than usual.

DLL Hijacking: The Trick of Impersonating a Legitimate

The call DLL hijacking involves tricking an application into loading a malicious library instead of the legitimate one.This method takes advantage of how Windows resolves paths and the search order for these libraries. It's a veteran method (known since the Windows 2000 era), but it's still very much alive.

Essentially, the attacker places a file with the same name as a DLL expected by a program, in a location that is evaluated before the actual directory in the search sequenceSince Windows does not always require absolute paths or verify the authenticity of the DLL by default, the application ends up loading the fake copy, activating the malicious code with the permissions of the compromised process.

On Microsoft systems, the standard DLL search order may vary depending on whether the DLL is enabled or disabled. Safe DLL Search ModeBut, to simplify, it usually follows a hierarchy similar to this:

• Directory from which the application is launched.
• System directory (for example, C:\\Windows\\System32).
• 16-bit system directory.
• Windows directory.
• Current work directory.
• System PATH environment variable directories.
• User's PATH environment variable directories.

When safe search mode is turned off, The user's current directory can move up positions in this list.increasing the risk that a DLL placed in a working folder will be loaded before the original system DLL.

The key to the attack is that Many applications do not specify the full path to the DLLs they needThey simply request to "load X.dll" and delegate the rest to the system. If a cybercriminal manages to place their own malicious X.dll file in the application directory or elsewhere, before System32, the system cannot easily distinguish between the genuine and the fake file.

Thus, a simple DLL file was able to catalyze one of the most serious cyberattacks suffered by the US administration, in which a DLL signed by a legitimate provider (SolarWinds) contained malicious payload that allowed entire networks to be compromised for months without being detected.

DLL hijacking variants and related tricks

Within the umbrella of the DLL kidnapping there are multiple variants that exploit different internal Windows mechanismsAlthough the goal is always the same (to introduce a malicious DLL into a legitimate process), the way to achieve it changes slightly.

Manipulation of KnownDLLs

Windows maintains a list of KnownDLLs, that is, system libraries that are considered known and trustedWhen a process requests one of these DLLs, the loader looks for it in a special directory and assigns it directly to the process's address space.

This list is controlled by registration keys. If an attacker manages to modify configurations related to KnownDLLsYou can exclude your malicious DLLs from this mechanism or manipulate how certain libraries are resolved, opening the door to unexpected substitutions or loads. To identify loaded libraries and outdated references, it's often helpful to check utilities like ListDLLs.

Side-Loading Attacks in WinSxS

Folder WinSxS (Windows Side-by-Side)The Windows directory, typically located at C:\Windows\WinSxS, stores multiple versions of components and DLLs. It is key for managing updates, backups, and compatibility with different library versions.

Many applications use WinSxS to avoid DLL version conflictsThis relies on manifests that specify which version of each library should be loaded at runtime. The problem is that these manifests are based on metadata that can sometimes be manipulated or exploited maliciously.

Recent research has shown that it is possible insert counterfeit DLLs into WinSxS and force certain legitimate binaries to load them, exploiting precisely how dependencies are resolved in that folder. This greatly expands the range of binaries that can be used to execute malicious code without needing to upload new executables to the system.

This technique is especially dangerous because It takes advantage of legitimate binaries already present in the WinSxS folder.It often avoids classic privilege escalation and generates less behavioral noise, increasing the chances of going undetected by many security solutions.

Ghost DLL hijacking

The call Ghost DLL Hijacking It relies on historical or marginally used DLLs that certain applications still attempt to load at startup, even though they are not strictly necessary. It's a kind of legacy from the past that many programs have never "cleaned up" from their initialization routines.

If an attacker identifies one of these forgotten DLLs, You just need to create a file with that same name and place it in a priority search path.Since the program cannot find the original, it will end up using the malicious version, which will load without much additional control.

Static analysis of suspicious DLLs: what to look for without executing them

When you suspect that a DLL may be malicious, there are two main approaches to analysis: static and dynamicStatic analysis involves extracting information from the file without running it, while dynamic analysis focuses on observing what it actually does when loaded in a controlled environment.

In the context of suspicious DLLs, Static analysis is fundamental for an initial risk assessmentIt allows you to review dependencies, exposed functions, metadata, internal structure, and possible signs of bundling or obfuscation, all without running the potentially dangerous code.

Classic tools such as PEiD, Dependency Walker or PEview They remain very useful for this type of review. For example, with PEiD you can examine the PE header, identify packers or compressors used, and list sections of the file.

One of the first checks will consist of review the import and export tableThere you will see which DLLs the suspicious library depends on (for example, KERNEL32.dll, USER32.dll, MSVCRT.dll) and what specific functions it calls: writing files (WriteFile), managing processes, manipulating memory, opening sockets, etc.

With Dependency Walker you will be able to navigating the dependency treeSee which DLLs are being loaded and which functions are being resolved in context. If you detect calls to sensitive functions (code injection, registry modification in critical areas, unexpected communications), raise the alert level.

PEview, for its part, facilitates detailed inspection of the file's internal structure: compilation timestamp, modified sections, import address tablesetc. Checking the timestamp can help you correlate the DLL with specific campaigns, check if it fits with other artifacts from the same attacker, or identify if it is a very recent binary with hardly any public references.

Manual loading, execution, and detection of DLL hijacking

To run or register DLLs in a Windows environment, utilities such as Regsvr32.exe and Rundll32.exeThe first is used to register the DLL in the system (for example, as a COM component), while the second allows calling specific exported functions from the command line. commands.

Attackers can automate the use of these tools through scripts (for example, in VBScript or PowerShell), integrating them into campaigns that overuse devices USB, scheduled tasks or macros in office documents to launch malicious DLLs without much user interaction.

If you suspect a possible DLL hijacking on a specific computer, a practical way to investigate is to use Process Monitor (Procmon) from the Sysinternals suiteThis tool allows you to view all input/output operations on the file system and registry in real time.

The usual procedure To detect DLL hijacking with Process Monitor, go through the following steps:

• Filter by the potentially affected applicationso that you only see the operations related to that process.
• Add a filter to show only files whose path ends in .dll, focusing on the loaded libraries.
• Apply a filter where the result is "NAME NOT FOUND"This indicates failed loading attempts or alternative paths where the same DLL is sought outside of system directories.

The resulting list of events You are displayed from external routes to the system, which is usually a clear symptom that it's looking for an alternative in less controlled directories. If you also filter by the application's own path, you can isolate the DLLs that are being resolved from the same directory as the executable, a typical behavior exploited by search order hijacking.

Why is it so difficult to distinguish between a false positive and dangerous DLL?

In a real business environment, it is common that Security solutions generate alerts about seemingly legitimate processes and DLLsA classic example is seeing threads or interactions between critical processes like winlogon.exe and csrss.exe, which may raise suspicions but, often, are part of normal system operation.

To refine your judgment and avoid panicking every time an alert is triggered, We need to look at the full context: file origin, reputation, digital signaturesuspicious name changes, binary size and structure, network behavior, disk operations, etc.

In cases such as a threading alert between winlogon.exe and crss.exe, the reasonable thing to do is Review active processes, DNS queries, disk writes, and security eventsIf everything points to a typical pattern, without strange connections or unusual modifications, it is legitimate to categorize it as a false positive, although it is always advisable to document the analysis.

The main difficulty is that The line separating a legitimate DLL from a malicious one that is very well disguised is becoming increasingly thin.especially when advanced techniques of obfuscation, bundling, or hijacking of system libraries are used.

Using artificial intelligence to detect suspicious DLLs

Given this scenario, security manufacturers have begun to invest heavily in Machine learning models specialized in DLL analysis and hijacking techniques. These models are not limited to searching for classic static patterns, but correlate a multitude of indirect signals.

An example of this can be found in the model developed by the Kaspersky AI Technology Research Center to detect DLL hijacking. Instead of only looking at the library's contents, the model focuses on contextual information: the path of the DLL and the executable that loads it, name changes, internal structure, size, digital signature integrity, previous file reputation, etc.

To train these types of models, large volumes of data are used on DLL load events collected from both internal analysis systems and anonymous telemetryprovided by users participating in cloud security networks (such as Kaspersky Security Network). The labeling relies on databases with established reputations.

The first versions of these models are usually still imprecise, but after several iterations of training, feature tuning, and tag debuggingA very high success rate is achieved, reducing false positives and improving the ability to identify subtle patterns associated with DLL hijacking.

In the specific case of the Kaspersky SIEM platform (Kaspersky Unified Monitoring and Analysis Platform), the model is integrated in two possible ways: in the event correlation engine and in the collection subsystemThe first method only analyzes events that have already triggered correlation rules, providing a second layer of rapid verification without overloading the infrastructure. The second method more broadly reviews all DLL load events that meet certain criteria, ideal for more comprehensive retrospective searches.

Other providers, such as Check Point, have developed specific engines such as DeepDLL, integrated into its ThreatCloud AI ecosystemThis engine examines metadata, attack strings, and the compiled structure of DLL files, cross-referencing the information with the arrival context (email, web download, MSI installers, compressed files, etc.).

According to data from the company itself, DeepDLL It achieves detection rates close to 99,7% with very few false positives.It is even capable of identifying samples that do not have the .dll extension but contain an equivalent internal structure. An illustrative case is the blocking of a malicious DLL embedded in an MSI installer, detected at the time of download before it could be executed.

What's interesting about these approaches based on IA es que improve with ThereThe more data they collect on threats and benign behaviors, the more they refine the models, and the better they adapt to new evasion techniques or variants not yet documented.

How to reduce the risk of DLL hijacking in Windows environments

The responsibility to stop DLL hijacking begins with the software developers themselves. One of the best practices is to always specify absolute paths for sensitive DLLsInstead of relying on the system's default search order, this significantly reduces the chances of a malicious library slipping into the load chain.

However, in practice, Not all projects adhere to secure coding guidelines.Therefore, organizations must complement that first level with a defense in depth that includes:

• Updated antivirus and EDRcapable of analyzing DLLs on disk, in memory and in transit, including behavioral and AI techniques.
• Specialized tools like DLLSPYdesigned to discover hijacking and privilege escalation vulnerabilities associated with the use of DLLs.
• Continuous monitoring of the attack surface, both on endpoints and servers, to identify routes and binaries that can be exploited in Side-Loading or Hijacking techniques.

A critical point is the staff training on phishing and social engineeringUltimately, for a malicious DLL to cause harm, someone has to introduce it into the ecosystem: opening a fraudulent attachment, running a manipulated installer, connecting a USB drive with suspicious content, etc.

It is advisable to reinforce clear policies, such as having a A well-communicated Information Security Policy, require the use of multi-factor authentication, and establish channels to report suspicious emails or files to a reference team before interacting with them.

In the third-party and supplier environment, the risk increases: Not all partners maintain the same level of ciberseguridadSupplier risk management tools allow you to monitor the security posture of the supply chain, launch questionnaires aligned with regulatory frameworks, and track the progress of corrective measures through dynamic risk scores.

The role of cleaning tools and preventative protection

In case of infection, there are utilities designed solely for remove malware already active on the systemsuch as the Microsoft Malicious Software Removal Tool (MSRT). It's important to understand that these tools are not a substitute for a full antivirus program.

MSRT, for example, It focuses on detecting and eliminating a specific list of widespread threats. (viruses, worms, Trojans) that are running at the time of the scan. It does not intend to cover the entire spectrum of malware, nor remove malicious software that is not active, nor deal with spyware or other more specialized threats.

The recommendation is clear: Use these cleaning tools as support after an infectionHowever, always keep an antivirus or EDR product installed and updated to block malware execution from the start. Also, keep in mind that if the system was already infected before deploying the antivirus, it may only detect some pieces of malware when the removal tool attempts to neutralize them. For practical guides on cleaning tools and initial analysis, it's helpful to consult resources on [topic missing]. cleaning and analysis tools.

This entire ecosystem of defenses, from traditional antivirus to AI-based engines, including SIEMs and cleaning tools, must work in a coordinated manner to minimize the window of opportunity for attackers who exploit suspicious DLLs.

Given the number of vulnerabilities published in recent years and the evolution of DLL hijacking towards more discreet techniques (such as WinSxS abuse or supply chain attacks), It is essential to treat suspicious Windows DLLs as a priority attack vectorUnderstanding how they work, knowing how to analyze them both statically and dynamically, relying on artificial intelligence to detect subtle patterns, and reinforcing training and security policies around them is what makes the difference between a simple alert and a high-impact incident that could have been avoided.