• Description
• Project Structure
• Environment Setup
• Preparing for usage
• Running scenarios
• Notes

How DLL hijacking works: an app loads the wrong DLL when path/search order can be influenced. This repository demonstrates a defensive method to mitigate this risk using a proxy DLL. It is crucial to recognize that this repository does not safeguard against all potential hijacking attacks. Nevertheless, the project can serve as a template or educational resource for the development of more robust systems.

Attacker places/creates a malicious DLL (SecureLib-real.dll) in the app directory. Malicious DLL exports the same functions but bypasses any checks and function calls (always returns true). As a result, the application would not work as expected, and an attacker could exploit this to compromise the application or system.

Application loads a proxy DLL (SecureLib.dll) that:

• Loads the real library (SecureLib-real.dll) from a known path,
• Verifies its integrity (hash/signature check),
• Logs and blocks if anything is off,
• Forwards calls safely to the genuine exports.

DLL proxying is not a silver bullet. If an attacker has the ability to replace files in the application directory (including the proxy DLL itself), they essentially have complete control over the application. This technique is most effective as part of a defense-in-depth strategy, complementing other protections like restrictive file permissions, code signing, and safe DLL search settings.

• SecureApp: An application that loads a DLL to perform sensitive operations.`
• SecureLib-real: The legitimate DLL that performs sensitive operations.`
• SecureLib: The proxy DLL that verifies and forwards calls to SecureLib-real.
• SecureLib-fake: A mock malicious DLL that simulates a hijacking attack. DLL exports the same functions as SecureLib-real, but bypasses any checks and function calls.`
• Hijacking-script: The script that performs the hijacking attack. It swaps SecureLib-real with SecureLib-fake in the application directory. As a result, the application will load a malicious DLL, in case it loads without Proxy DLL.`
• The output directory is Bin, containing all build binaries.

• Windows 10 or higher
• Visual Studio 2022 or higher
• C++20 and Platform Toolset v143

1. Clone the repository and open the solution in Visual Studio.
2. IMPORTANT: In Proxy.cpp need to replace G_EXPECTED_DLL_SHA256_HASH variable value with the expected SecureLib-real.dll hash. To obtain the hash, use a tool like certutil from Windows Command Prompt:

certutil -hashfile SecureLib-real.dll SHA256

3. Build the solution to compile all projects (x64 Debug/Release).
4. Prepare a test file with content in it. (In our example: test-file.txt)
5. Navigate to the Bin directory where the compiled binaries are located, and open Windows Command Prompt there.

Usage: SecureApp <proxy|direct> <license_key> <target_file_path>"

<proxy|direct> - choose whether to use the proxy DLL or load the real DLL directly.

<license_key> - the license key to validate.

<target_file_path> - the path to the test file to be processed.

1. Ensure that SecureLib-real.dllis present in the same directory as SecureApp.exe.
2. Run SecureApp using the command:

SecureApp.exe "direct" "SECRET-KEY-APRIORIT" "test-file.txt"

3. Observe that the application works correctly, using the real DLL.

1. Ensure that SecureLib-fake.dll and SecureLib-real.dll are present in the same directory as SecureApp.exe.
2. Run the hijacking script to replace the real DLL with the fake one. The script is located in :

Hijacking-script\SecureDllReplace.bat

3. Run SecureApp using the command:

SecureApp.exe "direct" "SECRET-KEY-UNKNOWN" "test-file.txt"

4. Observe that the application does not work as expected, as it loads the malicious DLL. License key check, encryption, and decryption are bypassed.

1. Ensure that SecureLib.dll (the proxy DLL) and SecureLib-real.dll (it is replaced by macilious DLL) are present in the same directory as SecureApp.exe.
2. Run SecureApp using the command:

SecureApp.exe "proxy" "SECRET-KEY-APRIORIT" "test-file.txt"

3. Observe that the application detected that the real secure DLL was tampered with. The application terminates without performing any operations. The message about the attack was logged.

1. Ensure that SecureLib.dll (the proxy DLL) and SecureLib-real.dll are present in the same directory as SecureApp.exe. NOTE: If the SecureLib-real.dll was replaced, rerun the hijacking script to restore the original DLL.
2. Run SecureApp using the command:

SecureApp.exe "proxy" "SECRET-KEY-APRIORIT" "test-file.txt"

3. Observe that the application works correctly, using the real DLL through the proxy. License key check, encryption, and decryption are performed as expected. During the loading of the DLL, the proxy verified the integrity of the real DLL.

The proxy currently uses a simple SHA-256 Hash verification. In a real-world scenario, the integrity check in the proxy DLL should be more robust, potentially involving digital signatures or more secure hashes.

Encryption and decryption in this example are simplified for demonstration purposes. In a production environment, use established libraries and algorithms for cryptographic operations.

Export coverage: In real life, a proxy DLL requires all exports (and honors calling conventions) for seamless behavior. Whenever the real DLL is updated, the proxy DLL must be updated accordingly to forward those new exports and possibly update the expected hash.

The repository was created in the context of Apriorit Blog Post.