Curated SIEM queries and techniques for offensive discovery of Windows privilege escalation, misconfigured ACLs, services, scheduled tasks, and vulnerable drivers.
Practical techniques for leveraging SIEM as an offensive discovery tool, helping defenders think like attackers to strengthen security from within.
See above - queries.md file.
Will keep getting updated when needed. The idea is to have layer on layer coverage using different event.codes/event.providers.
Queries for Vulnerability Management in file: vulnerabilitymanagement.md
We hope that you liked the presentation. Ping us if you (i would say when you) find vulnerabilities by using this method. A simple message like "one of your queries cathed good stuff".. is more then enough :) do it by commiting to the ping.md file or contact us in alternative ways! We would be happy to share your success!
The repo will assist you in having offensive mindset. Repo is to share the material and queries that we talked about in our presentation:
SEC-T september 2025 ⭐ https://www.youtube.com/watch?v=5nfL_4ek4dY
x33fcon updated talk june 2026 covering some new areas ⭐ https://youtu.be/dD_7AdEoj0k?is=CMp22Q9evBcqZe7L
We have included the most interesting ACL related parts and have tips & tricks.
Check out the outstanding webinars about windows local privilege escalation and windows endpoint misconfigurations which will assist you further on. There are more areas to look into.. This is only the starting point. If you build good queries in other areas - please share it with us so more in the community can use them.
The queries with ⭐ mark is extra highly relevant. The topics down below with ⭐ is really good content.
a must to watch, specially the ACL for binaries, services and schedule tasks.
Topic 2 (Insecurely installed/conf Software) And Topic 5 (Insecure Services And Tasks)
Make a process creation query using event.code 1 from SYSMON OR event.code 4688 (or the event.codes for services, schedule tasks, DLL load from C-root subfolders) Look for applications that are installed in C:\ root drive
C:\myapplication\myapplication.exe
C:\myapp\subfolder\myapp.exe
C:\SoftwareCompany\software.exe
C:\myapplication\myapplication.dll
C:\myapp\subfolder\myapp.dll
C:\SoftwareCompany\software.dll
The issue with applications that are installed in C-root folder is that it has per default incorrect ACL permissions which allows Authenticated Users to modify (M) the folder and possibly its files. If the Software installation does not correct the ACL in the installation process will likely result in a privilege escalation (confirm it) if a service or another high privileged process is spawning (ex. myapplication.exe OR myapp.exe) from one of the installation paths in C-roots subfolder.
Gives you an idea of which event codes to use what you will see in the event code it self.
Service security descriptors are not stored as plain SDDL in the registry. The registry only shows a Security subkey in binary format when:
Otherwise: The descriptor is computed from built-in defaults hardcoded in Windows.
Inside that key, you’ll find a value named Security showing Binary format of the SDDL for the service where you can look for to find misconfigured ACL for the service it self. Log them with a well configured Sysmon.
Gives you and idea of which event codes to use and what you will see in the event code it self.
UserId where S-1-5-18 is for the SYSTEM user.
GroupId where S-1-5-32-544 is for local Administrators group.
RunLevel where HighestAvailable will run the task as highest possible privilege for specified user. LeastPrivilege will run the task as lower set privilege (Medium integrity) but if the user is Administrator, a UAC bypass shall help you escalate privileges.
Check winlog.event_data.TaskContent in event.code 4698 for more context which contains almost most of the XML definition of the scheduled task, and it gives you the context of
What Microsoft should do is to add the <SecurityDescriptor> element to the event code 4698. When exporting a scheduled task manually gives you the SecurityDescriptor value in the exported XML but not allways in the event code itself.
“The SecurityDescriptor is included in the event, but it is only parsed and visible in events 4700 and 4701 (Task Enabled/Disabled), and is rarely present in 4698 (Task Created).”
Inside that key, you’ll find a value named SD showing Binary format of the SDDL for the Scheduled task where you can look for to find misconfigured ACL for the task it self. Log them with a well configured Sysmon.
Here is a excellent talk describing .sys files and privilege escalation using Bring Your Own Vulnerable Driver (BYOVD) techniques.
Summary of the talk showcases snowagent.exe dropping sys-files to C:\Windows\Temp\cpuz143\cpuz143_x64.sys and local privilege escalation by using the vulnerable driver for CVE-2021-21551.
The OpenSSL DLL (legacy) When compiled if not the --openssldir parameter is specified it defaults to /usr/local/ssl which is in Windows translated to c:/usr/local/ssl, which is a common path where the cnf will be looked for. It sets defaults for certificates/keys and can also load/configure crypto engines or providers. On Windows, it can reference an engine/provider DLL so OpenSSL can use extra cryptographic modules. This is what we can missuse and point it to a "malicious" dll. When a application initializes OpenSSL — it has to explicitly call OPENSSL_config(NULL) or CONF_modules_load_file(...) to process the config file. If it does not, your engine DLL (malicious one) from openssl.cnf will not be loaded.
Other common paths where applications may look for openssl.cnf is c:\etc\ssl\ or other custom user-writable paths.
openssl.cnf can instruct OpenSSL to load a custom DLL as a crypto engine:
openssl_conf = openssl_init
[openssl_init]
engines = engine_section
[engine_section]
dynamic = dynamic_section
[dynamic_section]
SO_PATH = C:\\path\\to\\evil.dll
LOAD = EMPTY
init = 0
A practical mental model is:
process loads libeay32.dll
→ process calls OPENSSL_config(NULL)
→ OpenSSL reads openssl.cnf
→ engine section causes loading of a specified dll load attempt
→ Windows loader accepts dll and its dependencies
If any step is missing, your DLL will not load.
A minimal rule you can use while debugging:
If the process only loads libeay32.dll, that is not enough. It must also call OpenSSL config loading and not disable it.
No signature check. No verification. Any DLL specified gets loaded, If the process calls OPENSSL_config. We can query for typical DLL names related to OpenSSL to enumerate possible applications to test more with. We want to check the DLLs OPENSSLDIR and if the process is calling the OpenSSL_conf. We can check OpenSSLDIR by checking file hash against the list in this repo, or get a copy of the crypto related dll and just run the openssldir_check on the cryptodll (libeay32.dll etc). We can also use ProcMon to check if the process calls any openssl.cnf. If we see openssl.cnf i procmon then we know for sure that the applications calls for it. In other methods what we want to get is version information (in fields of event.code 7) and which path it loads the openssl.cnf file from by checking file hash against the list in this repo, get a copy of same DLL and do manual check.
Example when running openssldir_check.exe
openssldir_check32.exe libeay32.dll
openssldir_check v1.0 by 0xm1rch
Output:
SSLeay_version() returned OpenSSL 1.0.1g 7 Apr 2014
SSLeay_version() returned OPENSSLDIR: "/usr/local/ssl"
Similar output with custom modified openssldir_check which is pre-compiled in this repo.
Output gives OpenSSL version 1.0.1g and that the OpenSSLDIR is set to /usr/local/ssl which is highly interesting!
Sysmon event.code 7 gives you loaded OpenSSL DLLs and also the version information for the dll in the file.pe.file_version field.
C:\usr\local\ssl\openssl.cnf on startup but that file is editable or missingopenssl.cnfResult: Local privilege escalation by planting a openssl.cnf which the applications openssl dll loads and ends with loading a custom "malicious" dll.
NSIS is a widely used Windows installer framework. The issue described here is that, when an NSIS installer or uninstaller runs with elevated privileges, it may use temporary directories under C:\Windows\Temp in a way that a normal local user can interfere with.
In practice, that means a low-privileged attacker can take control of files the installer trusts, such as temporary plugin files or uninstaller files, and turn that into code execution as SYSTEM. In other words, the weakness is not “the installer runs as admin,” but that the installer’s temp-file handling can let an unprivileged user hijack an elevated install or uninstall flow
Note: Some of these are official NSIS plugins, while others are common third-party plugins often used by NSIS installers.
Seeing one of these DLLs is a clue, but not absolute proof, that an installer uses NSIS. A file path ofC:\Windows\Temp\*.tmp\*.dllis a strong indication.
| DLL | Typical purpose | Type | Notes |
|---|---|---|---|
System.dll | Calls Win32 APIs and external DLL functions from NSIS scripts | Official NSIS plugin | One of the strongest indicators of NSIS |
nsDialogs.dll | Builds custom installer dialogs and controls | Official NSIS plugin | Common in modern NSIS installers |
nsExec.dll | Executes console commands and captures output | Official NSIS plugin | Often used for silent helper commands |
StartMenu.dll | Lets the user choose a Start Menu folder | Official NSIS plugin | Common in classic installers |
LangDLL.dll | Displays a language selection dialog | Official NSIS plugin | Often appears in multilingual installers |
Banner.dll | Shows banner/progress UI during install steps | Official NSIS plugin | Mostly cosmetic |
InstallOptions.dll | Creates older-style custom pages from INI definitions | Official NSIS plugin | Largely replaced by nsDialogs.dll |
UserInfo.dll | Retrieves information about the current user/account | Official NSIS plugin | Used for privilege or account checks |
Dialer.dll | Manages dial-up/network connection behavior | Official NSIS plugin | Mostly legacy |
Math.dll | Provides arithmetic helpers for NSIS scripts | Official NSIS plugin | Less commonly needed in newer scripts |
NSISdl.dll | Downloads files from the internet | Official NSIS plugin | Older download plugin; often replaced by inetc.dll |
Splash.dll | Shows a splash screen | Official NSIS plugin | Mostly legacy/cosmetic |
AdvSplash.dll | Shows a more advanced splash screen | Common NSIS plugin | Similar role to Splash.dll |
The following DLLs are especially suggestive of NSIS:
System.dllnsDialogs.dllnsExec.dllLangDLL.dllStartMenu.dllNSISdl.dllinetc.dllUAC.dllSome installers extract these DLLs temporarily into a folder like:
$PLUGINSDIRSo they may appear only at runtime, not next to the installer executable on disk.
DotLocal redirection abuse is a Windows DLL hijacking issue where a writable app folder lets an attacker trick a legitimate program into loading a malicious DLL first
DotLocal redirection vulnerability abuses Windows built-in .local / DotLocal DLL redirection feature. Windows supports DLL redirection by honoring a file or folder named like App.exe.local; when present, the loader checks the executable’s folder or that .local folder first for DLLs, and this can apply even when a full DLL path is specified. Microsoft documents this as a legitimate feature for redirecting DLL loads.
Why it becomes a vulnerability: if an attacker can write into the executable’s directory (User writable paths), or into a temporary extraction directory used by a privileged process, they can create Target.exe.local folder and place a malicious DLL where Windows will prefer it. That turns the feature into a DLL hijacking , so the trusted process loads attacker library instead of the intended library.
Identified high privileged processes in world writable paths should be investigated if they are vulnerable to DotLocal redirection. If you query for them and find applications. Do the last control using ProcMon to see if the process tries to load libraries from the created .exe.local folder. You can use the GetSxsPath tool to determine the full file path. Procmon should show you NAME NOT FOUND / PATH NOT FOUND events pointing to a .exe.local directory if its vulnerable. Based upon public reports applications during installation is particulary vulnerable during installation process.
A good rule of thumb is: ProcMon can provide evidence of .local probing, but the absence of a visible .exe.local miss does not prove the app is not susceptible. For comctl32.dll especially, the trace often reflects manifest/SxS binding rather than a simple app-folder DLL search.
C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e\comctl32.dll
C:\Path\To\Application.exe.local\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e\comctl32.dll
Determine redirection path for SxS DotLocal DLL Hijacking - https://gist.github.com/rxwx/1717e95e5ec11bea12d33e93a3832508
WiX Burn EXE bootstrapper Affected versions >= 4, < 4.0.4 < 3.14.0. This impacts any installer built with the WiX installer framework. WiX also lets authors replace the default icon and use either the stock WixStdBA UI or a custom bootstrapper application, so the EXE can be branded to look like the vendor rather than "WiX"
If the bundle is not run as admin, the user's TEMP folder is used and not the system TEMP folder. A utility is able to monitor the user's TEMP folder for changes and drop its own DLL into the .be/.Local folder immediately when the .be folder is created. When the burn engine elevates, the malicious DLL receives elevated privileges.
“A separate wixstdba.exe process is a good WiX Burn fingerprint, but the strongest indicator for the affected versions is the Burn engine version itself: vulnerable if it identifies as <3.14.0 or 4.0.0–4.0.3.”
Well configured SYSMON config to catch events that are of interest, like event.code 1, 7, 11 and 13 for the User-writable paths and the mentioned registry hives.
Enabled Advanced auditing for some of the Windows events.
Event ID 4688 (process creation) must be explicitly enabled to log newly created processes. By default, it does not capture the command line used to start the process; this feature must be specifically enabled in the security policy.
Scheduled task - 4698 is not enabled by default.
| Principal | Description |
|---|---|
| Everyone | All users, including Guests (and in older Windows versions, even Anonymous Logon). Very broad, usually restricted to read access. |
| Authenticated Users | Any account that has successfully logged in (local or domain). Excludes anonymous users. |
| BUILTIN\Users | The local Users group on the machine. Includes all standard (non-admin) local accounts. |
| INTERACTIVE | Any user logged in locally at the console (keyboard/session). Useful for differentiating local vs. remote access. |
| COMPUTERNAME\Username | A specific local account on that computer (e.g., LAPTOP01\Bob). Permissions apply only when that user logs on locally. |
| DOMAIN\Username | A specific domain account (e.g., CORP\Alice). Permissions follow the user across all domain-joined machines. |
Access Control List (ACL) attributes define what actions a user or group can perform on files or folders.
Here are some key ones worth noting:
| Attribute | Name / Meaning | Why It’s Interesting |
|---|---|---|
| F | Full Access | Grants all possible rights (read, write, execute, delete, change permissions, take ownership). Equivalent to "owner-level" control. |
| M | Modify Access | Allows reading, writing, and deleting files/folders, but not changing ACLs or ownership. Most common for regular users. |
| W | Write-Only Access | User can create or modify content but cannot read it back. Rare, but useful in "drop box" scenarios (e.g., secure file submissions). |
| WD | Write Data / Add File | Specifically allows creating or writing to files in a directory. Essential for being able to add or overwrite files inside a folder. |
| AD | Append Data / Add Subdirectory | On files: append data to the end of a file (cannot overwrite). On folders: create new subdirectories inside. |
You may need to do some whitelisting (see below for typical paths in ProgramData). The idea is to query typical user writable paths but it happens that the (files or folders) have correct ACL set. If offensive mindset does not help to escalate privileges - whitelist them. Filter out the less interesting ones: the ones with correct ACL, randomized file.names (filter out the folder). We want to reduce the noice and have a baseline. Its important to do this after verifying that its not a vulnerability. So you dont miss a Scheduled task that is vulnerable on every client.
You will likely need to whitelist the queries. Make your hunt, fine tune the queries and make alerts of them to catch new events that you have not looked into.
C:\ProgramData\Microsoft
C:\ProgramData\Package Cache
C:\ProgramData\Packages
etc.
Other ones that may need whitelisting, which may be common, is hardware related drivers and similar stuff that has randomized names..
Dont forget to query in the timespan of your "Log retention period". A good Methodology is to query in the beginning a short time frame which is progressivly increasing.
Do you hunt and check the interesting ones and fine tune and whitelist.. in the end make alerts of them to catch new events..
If a binary replacement is not possible because of correct ACL. Check folder permissions and if you have permissions to write files check if the executable tries to load any dlls that do not exist. If so, create them and you have your code execution. If binary replacement is not possible because its a running process. Check possible DLL sideloading or check if you as a regular user have permissions to restart the service it self. Another way is to check if you as a regular user can perform a "shutdown" that you escape in last second. A shutdown initiation stops processes and if you break out from it, you may be able to replace the binary of the terminated process. If the service is in Autostart mode and you dont have permissions to start/stop the service, what you can check is if you have SeShutdownPrivilege and if so initiate a reboot with shutdown /r /t 0.
If a service is spawning the process and if its not possible to replace binary, the binary does not try to load any missing DLLs. Dont give up - maybe the path is unquoted and you have write permissions and you can use that?
Build your queries layer on layer.. so check for service/schedule task creations, check for the process creation with parent as services or schedule task related process (svchost.exe with Schedule argument). Its possible that some system creates the service or schedule task but the binary path etc does not exist and the process creation never happens. But the vulnerability is still there and different events can be created related to it.
To reduce query load (performance) and probably whitelisting.. it may be a good idea to have queries separated for clients/servers. So a set of queries only used for the client endpoints and same set used for server endpoints.
The generic process creation by SYSTEM is high value query. It catches alot of scenarios.. besides of services and schtask spawning child processes it also catches msiexec.exe spawning a child process. It also caches if a executable from c:\windows\ccmcache is spawning a child process from a userwritable path. If we where to order executables in vulnerability i would still say that services.exe is related to software misconfigurations and schtasks is more a administrator misconfiguration..
If you have tried all queries and did not got successful. if you want to hunt deeper, and do a litte bit more work - go for every child process of services.exe and schtasks (svchost.exe with Schedule argument), regardless of where. Enumerate the enterprise and look for the ones in typical admin protected paths also (Program Files & Program Files (x86)). Its more common than you think that software vendors mess up the ACL even in typical protected paths. Use the process creation events and the events for services and schedule tasks. For Schedule tasks - query every Command field and Argument field. The argument field may be pointing to a script file in user writable path or C-root. The command fields may be pointing to a binary that has insecure ACL. You could also look into C:\PROGRA~3 which is the 8.3 short-name (DOS) representation of C:\ProgramData.
Its likely that if a user can trigger an installation, they can also trigger a uninstallation. Uninstall processes are of interest regardles of where the filepath is. If the ACL is not correct - a binary replacement will likely cause trouble. Query also for file creation of typical uninstall files by using Sysmon event.code:11. We want to do this to catch every uninstaller without trusting the process creation events. This is because its not common that users actually do uninstallation of installed applications.. They just dont care about that and therefor it will be easier to miss some uninstall events that exists but never are triggered.
uninstall.exe – Most generic and widely used.
unins000.exe, unins001.exe – Common with Inno Setup installers.
unwise.exe – Often used by older Wise Installer packages.
uninst.exe – Shortened version, often found in legacy software.
uninstaller.exe – Slightly longer, descriptive variant.
remove.exe – Sometimes used for minimal installers.
setup.exe (with /uninstall or /remove parameter) – Some apps reuse the installer executable for uninstallation.
appname_uninstall.exe (e.g., chrome_uninstall.exe)
update.exe (with --uninstall) – Seen with apps like Slack or Discord using Squirrel installers.
*_uninstall.exe – Many apps prepend the app name, e.g., teams_uninstall.exe, zoom_uninstall.exe.
*_cleanup.exe – Removal tools often have cleanup variants, e.g., driver_cleanup.exe.
*_remover.exe – Another common AV/vendor naming style.
| Extension | PE Type | Code execution on load? | Entry point / mechanism | Notes |
|---|---|---|---|---|
.exe | PE executable | Yes | PE AddressOfEntryPoint | Code starts when the executable is launched |
.dll | PE DLL | Yes | DllMain / TLS callbacks | Code can execute when DLL is loaded into a process |
.sys | PE kernel driver | Yes | DriverEntry | Driver initialization code executes when the driver is loaded |
.scr | PE executable | Yes | PE AddressOfEntryPoint | Essentially an executable; .scr is mainly a convention |
.cpl | PE DLL | Yes | DllMain + CPlApplet | Loaded by Control Panel infrastructure |
.ocx | PE DLL / ActiveX | Yes | DllMain + COM/ActiveX entry points | DLL initialization occurs when loaded |
.drv | PE DLL / legacy driver | Usually | DllMain or driver-specific entry point | Depends on the specific .drv type |
.efi | PE/COFF EFI binary | Yes | EFI entry point | Code executes when loaded by UEFI |
.ax | PE DLL | Yes | DllMain + DirectShow interfaces | DLL initialization occurs on load |
.acm | PE DLL | Yes | DllMain + ACM entry points | Loaded as an Audio Compression Manager codec |
.ime | PE DLL | Yes | DllMain + IME entry points | DLL initialization occurs when loaded |
.tsp | PE DLL | Yes |
| Extension | Language / Type | Purpose / Usage | Execution Context |
|---|---|---|---|
| .bat | Batch Script | Legacy command-line automation tasks, simple scripts | cmd.exe (Command Prompt) |
| .cmd | Batch Script (NT style) | Similar to .bat, preferred on NT-based systems | cmd.exe (Command Prompt) |
| .vbs | VBScript | Automation tasks, logon scripts, admin scripts | Windows Script Host (wscript.exe, cscript.exe) |
| .vbe | VBScript (encoded) | Encoded version of .vbs for obfuscation | Windows Script Host (wscript.exe, cscript.exe) |
| .ps1 | PowerShell Script | Modern Windows automation and configuration tasks | PowerShell (powershell.exe, pwsh.exe) |
| .js | JScript | Microsoft’s version of JavaScript for WSH tasks | Windows Script Host (wscript.exe, cscript.exe) |
| .jse | JScript (encoded) | Encrypted version of .js for obfuscation | Windows Script Host (wscript.exe, cscript.exe) |
| .wsf | Windows Script File (XML) | Mix VBScript, JScript, other scripts in XML format | Windows Script Host (wscript.exe, cscript.exe) |
| .wsh | Windows Script Host Settings | Configuration settings for WSH scripts | Windows Script Host (wscript.exe, cscript.exe) |
| .jar | Java Archive | Java applications packaged as a single file | java.exe (console) / javaw.exe (no console window) |
| .hta | HTML Application (HTA) | GUI-based Windows scripts using HTML, CSS, and JScript/VBScript | mshta.exe (Microsoft HTML Application Host) |
| .com | MS-DOS Application / DOS Executable | Legacy executable programs, small command-line utils |
Startup and Logon Scripts (and Shutdown or Logoff) are automation scripts that run (gpscript.exe) automatically on domain-joined computers or when users sign in, and they are commonly deployed using Group Policy Objects (GPOs) from a domain controller in a Windows Active Directory environment.
Startup/Shutdown
Logon/Logoff
When a startup/logon script runs via GPO:
| Hive / Path | Purpose |
|---|---|
| HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Logon | Tracks user logon scripts, their execution order, status, last run time, and parameters. |
| HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Logoff | Similar tracking for logoff scripts. |
| HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Startup | Startup scripts (applies to all users) tracking info. |
| HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Shutdown | Shutdown scripts info. |
Read the scripts that are run and look if there is any misconfigurations like other User-Writable paths or paths that does not exist or sensitive information. Look for possible used passwords (net use z: \server\share /user:domain\username password) or other sensitive information.
Logon Script Misconfiguration Categories
Logon Script Misconfigurations
If you want to enumerate possible events related to this is to query for msiexec.exe as parent process with cmd.exe OR conhost.exe OR powershell.exe OR pwsh.exe as child process. Contact the users your query get results from and ask them what they installed/repaired. You can also check event.provider: "MsiInstaller" and event.code: (1033 OR 11707) or similar to get more context about which msi installer was installed around same timestamp. You could also try this your self in Software Center and install the applications and look for command prompts which you can pause before they dissapear by marking a section in the window. Then break out using same techniques mentioned in the link below.
(event.provider: "Microsoft-Windows-Sysmon" AND event.code: 1 AND winlog.event_data.IntegrityLevel: System AND process.parent.name: msiexec.exe AND process.name: (cmd.exe OR conhost.exe OR powershell.exe OR pwsh.exe))
OR
(event.provider: Microsoft-Windows-Security-Auditing AND event.code: 4688 AND winlog.event_data.TokenElevationType: "%%1936" AND winlog.event_data.MandatoryLabel: "S-1-16-16384" AND process.parent.name: msiexec.exe AND process.name: (cmd.exe OR conhost.exe OR powershell.exe OR pwsh.exe))
In situations where available telemetry is limited, researchers can collect deeper host activity using boot logging in Process Monitor. Procmon can capture low-level system activity such as process creation, file access, registry operations, driver loads, and service activity starting very early in the Windows boot process in Microsoft Windows. The captured boot log can be exported to CSV and converted to NDJSON and ingested into a SIEM for further hunting and analysis. This approach can provide additional visibility when investigating privilege escalation or persistence techniques that might not appear in standard logging sources. Check the section procmon for more information.
To show you how common it is with misconfigured third party software.
| CVE | Vendor / Product | Path(s) / File(s) | Loads as SYSTEM | CWE | Notes |
|---|---|---|---|---|---|
| CVE-2025-42598 | Epson Printer Drivers | C:\ProgramData\EPSON\EPSON Series Dlls | spoolsv.exe / PrintIsolationHost.exe | CWE-276 | DLL overwrite → SYSTEM |
| CVE-2025-64669 | Windows Admin Center | C:\ProgramData\WindowsAdminCenter\Updater | WindowsAdminCenterUpdater.exe | CWE-276 | DLL Hijacking |
| CVE-2019-19363 | Ricoh Printer Drivers | C:\ProgramData\RICOH_DRV\ | PrintIsolationHost.exe | CWE-264* | DLL planting → SYSTEM |
| CVE-2025-1729 | Lenovo TrackPoint | C:\ProgramData\Lenovo\TPQM\Assistant | TPQMAssistant.exe | DLL Hijacking, Schtasks | |
| CVE-2025-47962 | Microsoft Windows SDK | C:\Microsoft Shared\Phone Tools\CoreCon\11.0\bin | cryptsp.dll | CWE-284 | DLL Hijacking, Service |
| CVE-2025-11772 | Synaptics Fingerprint | C:\ProgramData\Synaptics\CheckFPDatabase.exe | WTSAPI32.dll etc | DLL Hijacking USB Co-Installers | |
| CVE-2020-5896 | BIG IP F5 Client | C:\Windows\Temp\f5tmp\cachecleaner.exe | cachecleaner.dll | CWE-276 | DLL planting → SYSTEM |
| CVE-2020-13885 | Citrix Workspace App | %PROGRAMDATA%\Citrix\Citrix Workspace ####\webio.dll | Citrix services / uninstall | CWE-276 | DLL planting → SYSTEM |
| CVE-2018-17778 | SnowAgent | C:\Windows\Temp\cpuz143\cpuz143_x64.sys | snowagent.exe CPUID SDK | SYS file planting → SYSTEM | |
| CVE-2026-3991 | Symantec DLP Agent for Windows | C:\VontuDev\workDir\openssl\output\x64\Release\SSL\openssl.cnf | edpa.exe | LPE openssl.cnf | |
| CVE-2025-8069 | AWS Client VPN | C:\usr\local\windows-x86_64-openssl-localbuild\ssl | LPE openssl.cnf | ||
| CVE-2025-2272 | ForcePoint Endpoint DLP | C:\usr\local\ssl\openssl.cnf | ENdPointClassifier.exe | LPE openssl.cnf | |
| CVE-2025-13176 | ESET Inspect EDR | C:\src\vcpkg\packages\openssl_x64-windows-static\openssl.cnf | ElConnector.exe | LPE openssl.cnf |
BgImage.dll |
| Displays a background image in the installer UI |
| Official / common NSIS plugin |
| Mostly cosmetic |
inetc.dll | Downloads files over HTTP/FTP | Common third-party NSIS plugin | Very common in web installers |
InetLoad.dll | Downloads files from the internet | Common third-party NSIS plugin | Alternative to NSISdl.dll / inetc.dll |
UAC.dll | Handles elevation and UAC-related behavior | Common third-party NSIS plugin | Strong NSIS-related clue |
AccessControl.dll | Changes file/folder ACLs and permissions | Common third-party NSIS plugin | Used in admin-sensitive installs |
Registry.dll | Advanced Windows Registry operations | Common third-party NSIS plugin | More capable than built-in registry commands in some cases |
ShellLink.dll | Creates or edits Windows shortcut (.lnk) files | Common third-party NSIS plugin | Shortcut management helper |
SimpleFC.dll | Compares files or checks file differences | Common third-party NSIS plugin | Utility/helper plugin |
FindProcDLL.dll | Detects whether a process is running | Common third-party NSIS plugin | Often used before upgrades |
KillProcDLL.dll | Terminates running processes | Common third-party NSIS plugin | Common in uninstallers/updaters |
NScurl.dll | Downloads/transfers data using curl-style functionality | Common third-party NSIS plugin | Newer/more capable network helper |
ZipDLL.dll | Handles ZIP archive extraction or creation | Common third-party NSIS plugin | Archive utility |
unzipdll.dll | Extracts ZIP archives | Common third-party NSIS plugin | Older archive plugin |
untgz.dll | Extracts .tar.gz archives | Common third-party NSIS plugin | Less common, but seen in some packages |
VPatch.dll | Applies binary patches/updates | Common NSIS-related plugin | Often used in patch installers |
CabDLL.dll | Works with CAB archives | Common NSIS-related plugin | Mostly seen in older packaging workflows |
nsJSON.dll | Parses or generates JSON data | Common third-party NSIS plugin | More common in modern scripted installers |
StdUtils.dll | General-purpose helper utilities for NSIS | Common third-party NSIS plugin | Often used for OS/version/path helpers |
ExecDos.dll | Executes commands with better control over I/O and waiting | Common third-party NSIS plugin | Alternative/extension to nsExec.dll |
DllMain + TAPI entry points |
| DLL initialization occurs when loaded |
.pyd | PE DLL | Yes | DllMain + Python module initialization | Native Python extension |
.node | PE DLL | Yes | DllMain + Node.js addon initialization | Native Node.js addon |
.xll | PE DLL | Yes | DllMain + Excel XLL entry points | Loaded by EXCEL.EXE |
.wll | PE DLL | Yes | DllMain + Word add-in loading | Loaded by WINWORD.EXE |
| Executed directly as a program; on modern Windows, classic 16-bit .com programs run through NTVDM on 32-bit Windows, and are not natively supported on x64/ARM Windows |
| .chm | Compiled HTML Help | Offline help/documentation files for Windows programs | hh.exe (Microsoft HTML Help Viewer) |
| CVE-2024-6975 | Cato Client | C:\Work\WinVPNClient\ThirdParty\openssl\openssl-3.1.1\VS2022\SSL64\openssl.cnf | winvpnclient.cli.exe | LPE openssl.cnf |
| CVE-2023–6338 | Lenovo UDC | C:\J\w\prod\BUildSIngleReference....... | UDClientService.exe | LPE openssl.cnf |
| CVE-2023-41840 | FortiClient Windows OpenSSL component | CWE-426 | openssl.cnf |
| CVE-2021-21999 | VMWare Workstation tools | LPE openssl.cfg |
| CVE-2020-8224 | Nextcloud windows desktop application | C:\usr\local\ssl\openssl.cnf | nextcloud.exe | LPE openssl.cnf |
| CVE-2020–26050 | SaferVPN | C:\etc\ssl\openssl.cnf | C:\Program Files (x86)\SaferVPN for Windows\bin\openvpn.exe | LPE openssl.cfg |
| CVE-2019-12572 | PIA Windows service | C:\etc\ssl\openssl.cnf | pia-service.exe | LPE openssl.cnf |
| CVE-2024-34474 | Clario for Desktop | C:\ProgramData\Clario\ | ClarioService.exe | CWE-276 | Loads DLLs from ProgramData |
| CVE-2022-34043 | NoMachine (Windows) | C:\ProgramData\NoMachine\var\uninstall\ | Uninstaller | CWE-732 | DLL hijack in uninstall folder |
| CVE-2020-15145 | Composer-Setup (Windows) | C:\ProgramData\ComposerSetup\bin\composer.bat (+ DLLs) | Maintenance/repair actions | CWE-276 | Writable bin → LPE |
| CVE-2019-14935 | 3CX Phone for Windows | %PROGRAMDATA%\3CXPhone for Windows\PhoneApp\ | Startup / elevated context | CWE-732 | Everyone:Full Control |
| CVE-2024-54131 | Kolide Launcher | C:\ProgramData\Kolide\Launcher-[ID]\data\ | Launcher service | CWE-276 | Weak perms → DLL load |
| CVE-2021-28098 | Forescout SecureConnector | %PROGRAMDATA%\ForeScout SecureConnector\ | SecureConnector service | CWE-264* | Writable log → symlink → SYSTEM |
| CVE-2019-15752 | Docker Desktop (Windows) | %ProgramData%\DockerDesktop\version-bin\docker-credential-wincred.exe | Docker auth flow | CWE-276 | EXE planting → SYSTEM |
| CVE-2022-39959 | Panini Everest Engine | %PROGRAMDATA%\Panini\Everest Engine\EverestEngine.exe | Engine service (SYSTEM) | CWE-276 | Unquoted path → EXE planting |
| CVE-2018-10204 | PureVPN (Windows) | %PROGRAMDATA%\purevpn\config\config.ovpn | openvpn.exe (service) | CWE-276 | Writable config → DLL load |
| CVE-2020-27643 | 1E Client (Windows) | %PROGRAMDATA%\1E\Client\ | Client service | CWE-276 | Writable dir → LPE |
| CVE-2020-1985 | Palo Alto Secdo Agent | C:\ProgramData\Secdo\Logs\ | Secdo service | CWE-276 | Incorrect default perms |
| CVE-2024-36495 | Faronics WINSelect | C:\ProgramData\WINSelect\WINSelect.wsd / Faronics\StorageSpace\WS\WINSelect.wsd | WINSelect service | CWE-276 | Config writable → LPE |
| CVE-2024-20656 | Visual Studio Setup WMI | C:\ProgramData\Microsoft\VisualStudio\SetupWMI\MofCompiler.exe | Repair action (SYSTEM) | CWE-276 | Replace binary → SYSTEM |
| CVE-2025-3224 | Docker Desktop (Windows) | C:\ProgramData\Docker\config\ | Updater (high priv) | CWE-276 | Creatable/deletable path → LPE |