▄████████ ███▄▄▄▄      ▄████████  ▄█       ▄██   ▄      ▄████████  ▄█     ▄████████      ████████▄   ▄█        ▄█       
  ███    ███ ███▀▀▀██▄   ███    ███ ███       ███   ██▄   ███    ███ ███    ███    ███      ███   ▀███ ███       ███       
  ███    ███ ███   ███   ███    ███ ███       ███▄▄▄███   ███    █▀  ███▌   ███    █▀       ███    ███ ███       ███       
  ███    ███ ███   ███   ███    ███ ███       ▀▀▀▀▀▀███   ███        ███▌   ███             ███    ███ ███       ███       
▀███████████ ███   ███ ▀███████████ ███       ▄██   ███ ▀███████████ ███▌ ▀███████████      ███    ███ ███       ███       
  ███    ███ ███   ███   ███    ███ ███       ███   ███          ███ ███           ███      ███    ███ ███       ███       
  ███    ███ ███   ███   ███    ███ ███▌    ▄ ███   ███    ▄█    ███ ███     ▄█    ███      ███   ▄███ ███▌    ▄ ███▌    ▄ 
  ███    █▀   ▀█   █▀    ███    █▀  █████▄▄██  ▀█████▀   ▄████████▀  █▀    ▄████████▀       ████████▀  █████▄▄██ █████▄▄██ 
                                    ▀                                                                  ▀         ▀        
Using DLL hijacking to aid in malware analysis.

=====|=================== Home ===================|=====
Research - Nerd section.
Primers on DLLs - Basic information needed to understand DLLs.
Types of DLL Hijacking - According to the MITRE ATT&CK framework.
References - Credits where credits are due.
=====|============================================|=====
DLL Research - Nerd section.
DLL hijacking is a vulnerability in Windows DLL load order in which a malware loads its own malicious DLL that will be run before a legitimate one does; this way, it can handle any calls made and execute the contained code with the same privileges as the running application.

With that in mind, the idea was to use this same technique and turn it around; is it possible to trick malware into calling DLLs that were specifically modified to handle malicious events? Understanding this could help in malware analysis by automating and deciding how to handle malicious activity executed through DLLs.
The objective for this type of DLL hijacking substantially changes; rather than achieving privileged execution, the DLL was going to modify any returns to calls made by the malware without directly interacting with the malicious process.

Primers on DLLs - Basic information needed to understand DLLs.
The first thing we need to know is that when software is compiled, it is either:
Statically linked in which library code is directly embedded into the executable at compile time (self contained programs).
Dynamically linked in which libraries are loaded at runtime and are expected to already be present on the system.
Now might be a good idea to brush up on what and how DLLs work; a dynamic link library (DLL) is a file that contains code and data that can be used by other programs. Dynamic link libraries are only used, unexpectedly, in dynamically linked software. It works in the same way a code library works during development but the advantage is that these dynamic libraries reside on systems and generally don't need to be shipped with every piece of software.

DLL search order - How DLLs are located and used.
Name resolution is a process in which the system is responsible for converting the name of a binary into a physical on-disk file; what this means is that, in cases in which a program can't know beforehand the location of needed directories, the system takes it up to locate the required resources by resolving binary dependencies and LoadLibrary operations. Developers are no longer hardcoding directories but rather just asking the system for a file handle.
Normally, Windows will use a so-called search path which is a list of locations that are sequentially searched for a specific resource. Before the search path is engaged though, there are some other specific mechanisms that take precedence and that we need to keep in mind:
DLL Redirection which allows different software that use the same DLL but in different versions to specifically select the correct version they need.
API Sets which are virtual aliases for other .dll files that allow for dynamic resolution.
SxS Manifest Redirection WIP
Loaded-Module List WIP
Known DLLs WIP
Package Dependency Graph of Process WIP
System search locations WIP
  ┌ DLL Search Order  ────────────────┐
│ │          DLL Redirection          │
│ ├───────────────────────────────────┤
│ │             API Sets              │
│ ├───────────────────────────────────┤
│ │     SxS Manifest Redirection      │
│ ├───────────────────────────────────┤
│ │        Loaded-Module List         │
│ ├───────────────────────────────────┤
│ │            Known DLLs             │
│ ├───────────────────────────────────┤
│ │     Package Dependency Graph      │
│ ├───────────────────────────────────┤
▼ │      System Search Locations      │
  └───────────────────────────────────┘
Now let's take a slightly deeper dive into each one of these:
DLL Redirection was created to solve compatibility issues when there are two distinct softwares that use the nominally same DLL but with different versions; according to the changes in the code, this could cause one of the two softwares to break.
This Windows mechanism allows a developer to tell the Windows DLL loader to first check a specific folder for DLLs before falling back to the system search order and was originally thought for testing, debugging and updating Windows DLLs.

DLL redirection needs to be enabled by modifying a registry key, specifically HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options, and adding a new DWORD value named DevOverrideEnable with the value of 1; this can be achieved with the following powershell command:
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options" /v DevOverrideEnable /t REG_DWORD /d 1
    
API Sets
WIP
    
SxS Manifest Redirection
WIP
    
Loaded-Module List
WIP
    
Known DLLs
WIP
    
Package Dependency Graph of Process
WIP
    
System Search Locations
Initially, the system search order checked the binary directory and the current working directory before any system directries. This behavior worked until it didn't, since binary planting later came along as a precursor to DLL hijacking: load operations were overridden with malicious binaries that had the same name but were placed in the current working directory which could potentially be freely accessed by anyone.
Safe DLL search mode was later on added and fixed this problem; the current directory was moved behind three system directories. This search mode is still up and running today, sequentially looking through these directories:
The directory from which the binary is launched.
The system directory (C:\Windows\system32)
The 16-bit system directory (C:\Windows\System)
The Windows directory (C:\Windows)
The current working directory at binary launch time (which can be the same as 1)
The directories listed in the %PATH% environment variable.
Notably, a binary can change these elements during its own execution; calls to the SetEnvironmentVariable, SetCurrentDirectory and SetDllDirectory APIs can and are used to achieve this amongst other ways.

┌ Safe DLL Search Order ──────────────┐                                        
│    ┌───────────────────────────┐    │                                        
│    │ Binary Launch Directory   │    │                                        
│    └───────────────────────────┘    │                                        
│                 │                   │             (For reference)            
│                 ▼                   │                                        
│    ┌───────────────────────────┐    │    ┌ Old DLL Search Order ────────────┐
│    │ System Directory          │    │    │  ┌────────────────────────────┐  │
│    │ C:\Windows\System32       │    │    │  │  Binary Launch Directory   │  │
│    └───────────────────────────┘    │    │  └────────────────────────────┘  │
│                 │                   │    │               │                  │
│                 ▼                   │    │               ▼                  │
│    ┌───────────────────────────┐    │    │  ┌────────────────────────────┐  │
│    │ 16-bit System Directory   │    │    │  │ Current Working Directory  │  │
│    │ C:\Windows\System         │    │    │  └────────────────────────────┘  │
│    └───────────────────────────┘    │    │               │                  │
│                 │                   │    │               ▼                  │
│                 ▼                   │    │  ┌────────────────────────────┐  │
│    ┌───────────────────────────┐    │    │  │ System/Windows Directories │  │
│    │ Windows Directory         │    │    │  └────────────────────────────┘  │
│    │ C:\Windows                │    │    │               │                  │
│    └───────────────────────────┘    │    │               ▼                  │
│                 │                   │    │  ┌────────────────────────────┐  │
│                 ▼                   │    │  │ PATH Environment Variable  │  │
│    ┌───────────────────────────┐    │    │  └────────────────────────────┘  │
│    │ Current Working Directory │    │    └──────────────────────────────────┘
│    └───────────────────────────┘    │                                        
│                 │                   │                                        
│                 ▼                   │                                        
│    ┌───────────────────────────┐    │                                        
│    │ PATH Environment Variable │    │                                        
│    └───────────────────────────┘    │                                        
└─────────────────────────────────────┘                                        
DLL redirection - What if developers need to directly modify the search order?
As with a lot of things, there are some cases in which there is a legitimate use of modifying the DLL search order and Windows does provide a method to do it: DLL redirection allows the loading of alternate copies of DLLs for purposes such as testing. This means that you can add instructions for Windows to bypass search order and use your own DLLs instead of official ones. Actually, it doesn't directly bypass but rather checks DLL redirection before it goes through normal search order.

How does malware hijack DLLs? - According to the MITRE ATT&CK framework.
As we may have noticed, the safe search order may help in securing in part but if we can correctly choose where to store our DLL then we can still beat the legitimate DLL in loading times.
Next on the chores list, we need to do some research on some well-known DLL hijacking techniques: this brings us to the good old MITRE ATT&CK T1574.001 which gives an initial idea:
DLL Sideloading
Consists of hijacking which DLL a program loads by planting it and then invoking a legitimate application that executes the malicious DLL payload. This is usually taken advantage of when the malicious DLL needs to mask its actions behind a victim application which is legitimate and trusted.
    
DLL Search Order Hijacking
The default search order that Windows uses to load DLLs is hijacked, allowing a malicious DLL to be prioritized over a legitimate library. Windows entirely makes the decision in this case.
    
DLL Redirection
Modifies the search order via DLL redirection which has to be enabled in the Registry or via the creation of a redirection file, causing a program to load a DLL from a different location.
    
Phantom DLL Hijacking
Targets references to non-existent DLL files and loads a malicious library with the correct name in the location of the missing module.
    
DLL Substitution
Directly substitutes the legitimate DLLs with malicious ones.
All these techniques notably revolve around the search order, either by playing on priority or by modifying legitimate DLLs. 
In general, DLL hijacking will cause programs to still behave normally because, after executing their payload, they can redirect the call to the benign library to evade detection. This is a note that's being saved here since I'm thinking about having some calls modify the actual behavior whereas only want logging capabilities for others.
Of these techniques, DLL search order hijacking, DLL redirection and DLL substitution seem like the best directions for what we're trying to do here. Admittedly, DLL substitution is surely the easiest and most straight forward and shouldn't cause any major problems since this project is aimed for analysis VMs but we'll still play around with each technique a bit for fun.

=====|==================== Top ===================|=====
References - Credits where credits are due.
itm4n - Aside from generic/standard reference websites, a good deal of help was from itm4n's blog that explains DLL hijacking theory and was nice to read up on.
Official Microsoft Documentation:
What is a DLL - Microsoft Learn
DLL Search Order - Microsoft Learn
Dynamic-link library redirection - Microsoft Learn
Windows API Sets - Microsoft Learn
About Side-by-Side Assemblies - Microsoft Learn
Windows Internals Part 1 and 2 is a pretty recognized Windows reference which is nice to have for anything Windows related. More info on Microsoft Learn.