This article examines DLL-hijacking and how it can be used by threat actors as an attack vector in cyber security exercises. The skills and knowledge were partly acquired at the Disobey 2024 event and are applied to development of real attack techniques for cyber security exercises. This article contains an example of developed realistic DLL-hijacking attack scenario for cyber security exercises.
What is a cyber security exercise?
A cyber security exercise is a simulation based on real-world events designed to increase realism on selected scenarios. It involves a Red Team simulating adversarial attacks, while the Blue Team (the training audience) must defend. Multiple organizations can participate from commercial to governmental, reflecting interdependencies in business services. Exercises are scoped to specific organizational needs and include planning, execution, and review phases. These exercises take place in a cyber range, replicating real-world environments. By exercising Blue Team’s members will learn to investigate cyber-attacks in a safe environment that simulates the organization’s environment. (JYVSECTEC, n.d.-a.; Karjalainen et al., 2019.)
In JYVSECTEC these exercises are conducted in Realistic Global Cyber Environment (RGCE) which is an advanced, fully equipped live cyber range. It simulates a realistic global landscape alongside authentic organizational environments within a secure, private cloud. By leveraging cutting-edge virtualization techniques, integrating physical devices, and incorporating business-specific systems, RGCE offers an immersive and highly accurate cyber ecosystem. Furthermore, it allows customization to meet the unique training, exercise, or research and development requirements of any organization, providing tailored environments to suit specific goals and scenarios. (JYVSECTEC, n.d.-b.)
What is DLL-hijacking and DLL sideloading?
DLL-hijacking is a technique where attackers inject malicious code into an application by taking advantage of method how some Windows applications locate and load Dynamic Link Libraries (DLLs). The attack involves replacing a legitimate DLL with a malicious one and placing it in a location where the application is likely to load it. When the application starts, it unknowingly activates the malicious code. For the attack to work, the victim must load the infected DLL from the same folder as the targeted application. The technique has been around for a very long time. While the method properties are known, the technique still has a few upsides for the attacker. For example, the hijacked application image continues to have known checksums and signatures on disk, but the process also loads contents to planted new files. It’s not uncommon to have application folders with known good files with some new unseen files as legitimate plugins. (Kost, 2024; Allsopp, 2017, 141-142, 151.)
DLL sideloading is a common DLL-hijacking technique, in which the attackers exploit a legitimate executable that loads a DLL by name rather than by full directory path. They replace the legitimate DLL with a malicious one, renamed to match the legitimate DLL’s filename. (Fakterman et al., 2024.)
DLL-hijacking method is highly relevant because it demonstrates the vulnerability of supply chains and how attackers can gain widespread access through trusted third-party software. A really good example of this is the SolarWinds attack. SolarWinds attack began in March 2020, it involved malicious code to be inserted into a software update from SolarWinds which is a widely used IT management company. This supply chain attack gave cybercriminals access to U.S. government departments, including Energy, State, and Homeland Security, among others. The attackers are believed to be linked to a nation state threat actor. This method is highly relevant because it demonstrates the vulnerability of supply chains and how attackers can gain widespread access through trusted third-party software. (Kost, 2020.)
Supply chain DLL sideloading for elevated command and control
From information learned at Disobey we have created a supply chain attack scenario where malicious DLL sideloading malware technique is used to get command and control (C2) connection. To get supply chain attack vector working, the attackers need to modify the latest 32-bit or 64-bit Windows installer of some executable, such as Notepad++ and have it distributed. The modified version plants three additional files alongside the Notepad++ installation: version.dll, libcurl.dll and eula.dll. From these additional files only version.dll is modified heavily in-house to work to our cause.
In this scenario we assume that the attackers have not infiltrated the source code repository of Notepad++ as the infection is implemented as a simple DLL-hijack. This attack method exploits the way Windows applications search and load DLLs.
In this scenario we assume that the attackers were able to affect some later stage in Notepad++’s Continuous Integration (CI) pipeline to add additional files.
Infection as a service
It is normal to have threat actors which are selling their programs to get infection for the initial access to some environments. After initial access original threat actor does not have any other malicious intents and they can sell this access to some other threat actor which uses it to exploit further. In this case DLL sideloading can be used as an attack vector to get initial access and it is sold to other threat actors. Threat actor could offer this infection as a service, they will get money from other threat actors who are using this initial access to conduct more attacks on the environment where initial access is. This is a win-win situation to both threat actors. In this scenario it is likely that the original threat actor is selling access to infected hosts as per host basis. There could be links to this in the underground forums when executing this scenario.
Deeper understanding about the files needed to create this supply chain attack vector
The file libcurl.dll is a non-modified 32-bit CURL dll. This file is used by the C2 trojan downloader. This file is not malicious, but without finding this exact version present in the system attack won’t be possible because system prompts for further lookups of these files.
The file eula.dll is also not malicious, but an original Windows 10 version.dll. It is included to make fake version.dll calls consistent to original version.dll (eula.dll) and software will work as intended using eula.dll.
The file version.dll contains the C2 trojan downloader, which is the attacker’s program. This is later referred simply as the “downloader”. This file is placed in the Notepad++ directory to hijack the search path of “version.dll” loaded by Notepad++ in startup. When analyzing this file, we can focus on properties of the 50190 bytes of this file. In the cyber security exercises, there are technical people who will investigate possible malicious programs to find out what they are doing. For that reason, we have made the malicious binary to behave like a debug version to be easier to reverse engineer, as it contains multiple unique strings, many of which seem to be print statements to indicate the current state of the application. This also makes reversing this sample easy. Later samples likely omit these strings, which do not appear to the user anyway.
Startup
In this scenario we use Notepad++ as the infected application. When the user opens Notepad++, downloader code from the version.dll activates. There is a simple startup delay of 10 seconds, possibly to evade poorly implemented sandboxes and AV products. After this initial delay, the downloader makes contact to C2 server.
Domain generation algorithm
The downloader contacts C2 server between dynamically configurable sleep times. The domain is generated from three parts, where the last is “thisistest.com” and middle parts alternate between
- middle-part-test1
- middle-part-test2
- middle-part-test3
- middle-part-test4
First part of the domain is generated by concatenating username and host/domain of the host. This part is encrypted using Caesar’s cipher (Buchanan 2017, 14).
C2 protocol
The C2 protocol is based on HTTP requests where the various fields are separated by newlines. The requests are in form of
“xxx.middle-part-test1.thisistest.com/something?s=1621171907&c=1621185612”
This downloader version has essentially only two modes: either continue sleeping or download and execute a payload. The C2 traffic consists mostly of commands to continue sleeping, therefore when the traffic is analyzed during cyber security exercise there will be a lot of instructs to continue sleeping and not so many commands to run actual payloads. Analyzing traffic is important to know if the C2 server is actively sending and receiving data or payloads.
Our C2 server can instruct the downloader to
- download payload from given URL (url)
- place it to temp files (target filename)
- execute it.
How to reveal this attack vector
In this case temporary filename is an indicator of compromise. Before the downloader accepts the command, it verifies that the target filename starts with “bw_”.
This means that a created temp file starting with “bw_” is an excellent indicator that a payload was downloaded and likely executed. Also, lack of created “bw_” temp files is an excellent indicator for a still dormant C2 downloader if it is present in the system.
If it is possible to determine that no such files were created, then the system is untouched from any further infections and, what comes to this downloader version, is clean. The lack of file creation should be verified from event logs that are preferably non-local. In this case simply closing existing Notepad++ processes and uninstalling/removing the infected Notepad++ version is enough to mitigate the situation. This scenario was designed for a cyber security exercise. In the exercise we can observe that several downloader payloads can be seen to come from threat actor, which quickly makes its presence known by ransoming the victim and does not bother to remove its temporary artifacts or clean even local event logs.
Spawning the payload
Another location where the C2 name appears is where the started payload is executed if it ever happens. This would occur after the program downloads a suitable DLL payload from an URL pointed by the server.
The C2 downloader executes downloaded 32-bit or 64-bit DLLs that are named with prefix “bw_” and the exported function named “C2” must be present. Other possible variations for export function can be used, such as “DllRegisterServer”.
Conclusion
At the Disobey event Anne Hautakangas (2024) gave a presentation on how we can make DLL sideloading as part of DLL-hijacking to be a successful attack vector. Now we have managed to create a successful scenario while using it. Also, at Disobey presentation by Jason Lang (2024) we got more information about real life modern attack scenarios where breach has already happened.
DLL-hijacking attacks like DLL sideloading is still very popular and should be taken seriously. This technique is also difficult to detect and for that reason it is popularly used by adversaries (Johnson, 2023). DLL sideloading is being leveraged for example by few known ransomware operators like Revil, Rorschach and Babuk (Conrad, 2024). It has been seen that also APT Cloaked Ursa (aka APT29) has been seen using this technique (Fakterman et al., 2024). This being the main reason for developing this technique led us to create more realistic red team operations at the Realistic Global Cyber Environment (RGCE).