Sigma detection rules, expert-reviewed

Malicious Phantom DLL Hijacking of wlbsctrl or TSMSISrv Loaded by svchost

This rule detects svchost.exe loading wlbsctrl.dll or TSMSISrv.dll, which are non-present phantom DLLs abused for hijacking. In the PassiveNeuron campaign attackers placed malicious copies of these DLLs so that svchost would load their implant during service startup. Because these libraries are not shipped by default Windows in the search path svchost uses, their presence indicates phantom DLL hijacking for stealthy persistence and privilege escalation.

Suspicious DLL Hijack via BugSplatRc64 Sideloading (via image_load)

This rule detects loading of BugSplatRc64.dll from a signed loader named nau.exe used to sideload a Cobalt Strike beacon in the GitHub and social-media delivery campaign. The attacker abuses the search-order of a legitimate application to run their DLL under a trusted process name. Pairing the loader name with the hijacked module distinguishes this from benign crash-reporting usage.

Suspicious Exchange IIS Worker Loading GhostContainer Module (via image_load)

This rule detects the Exchange IIS worker process loading the App_Web_Container_1.dll module associated with the GhostContainer backdoor. GhostContainer registers itself as an Exchange component and patches AMSI and ETW in the w3wp process to disable in-memory inspection. Loading this named module in the Exchange worker indicates in-process backdoor persistence on a mail server.

Malicious USERENV.dll Sideloaded by AppVShNotify.exe

This rule detects AppVShNotify.exe loading a USERENV.dll from outside the System32 directory which indicates DLL search-order hijacking. Lazarus abused this signed Microsoft binary during Operation SyncHole to sideload a malicious loader DLL. A userenv module resolved from a non-system path is the hallmark of the sideloading chain.

Malicious CiscoSparkLauncher DLL Sideload From AppData via image_load

This rule detects CiscoSparkLauncher.dll being loaded from a user AppData directory which is the sideloading vector for the MysterySnail RAT. IronHusky paired a legitimate CiscoCollabHost host binary with a malicious CiscoSparkLauncher.dll planted under AppData to gain execution. A Cisco DLL loading from a user profile path rather than Program Files strongly indicates sideloading abuse.

Malicious ESET Scanner Version DLL Sideloading via image_load

This rule detects the ESET command line scanner ecls.exe loading a version.dll from a directory other than the Windows system folders which indicates DLL search order hijacking. ToddyCat abused CVE-2024-11859 to make the ESET scanner proxy load a malicious version.dll named TCESB from an attacker path. DLL proxying through a trusted security binary is a stealthy loader technique that evades many controls.

Suspicious Side-Loaded D3D12_1core DLL Loaded by BellaCPP

This rule detects loading of D3D12_1core.dll, a non-standard DLL side-loaded by the BellaCPP backdoor to execute its payload under a trusted host process. The name mimics legitimate Direct3D components but is not a genuine Windows library. Loading of this DLL indicates BellaCPP side-loading activity.

Suspicious wlbsctrl.dll Sideloading via IKEEXT Service

This rule detects svchost loading wlbsctrl.dll from outside System32, a phantom-DLL sideloading path abused via the IKEEXT service to run attacker code in the incident-response cases. Because wlbsctrl.dll is normally absent from the system, a service loading it from a non-System32 location indicates persistence via DLL hijacking.

Suspicious libEGL.dll Side-Loading from Public Libraries Directory (via image_load)

This rule detects a load of libEGL.dll from the C:\Users\Public\Libraries directory. The Ducktail toolset places a malicious libEGL.dll in Public\Libraries to be side-loaded by a signed host binary, so a load of this graphics-named DLL from a world-writable staging path indicates DLL side-loading rather than legitimate rendering support.

Suspicious Side-Loading of wbemcomn.dll or ESENT.dll from Non-System Path (via image_load)

This rule detects a load of wbemcomn.dll or ESENT.dll from a directory outside the standard Windows system folders. Lazarus deploys its LPEClient downloader as a rogue wbemcomn.dll or ESENT.dll that is side-loaded by a signed host process, so a system-named DLL loading from an unexpected path signals DLL search-order hijacking used to stage further payloads.

Suspicious Python Script Persistence in User Startup Folder

This rule detects a Python script being written into the Windows Startup folder. The Arkanix stealer establishes persistence by dropping hvnc.py into Startup so its hidden VNC module relaunches at logon as documented by Kaspersky. A .py file placed in Startup is highly unusual for legitimate software and indicates script-based autostart persistence.

Suspicious OneDrive Masquerading TLB Marker File in ProgramData

This rule detects the creation of a file named MicrosoftOneDrive.tlb directly in the ProgramData root. HoneyMyte used this file as an infection marker while masquerading as a legitimate OneDrive component as reported by Kaspersky. A type library file impersonating OneDrive at this location indicates implant staging and masquerading.

Suspicious MgBot Marker Files Created in ProgramData Microsoft Folders

This rule detects the creation of status.dat or perf.dat files inside the ProgramData Microsoft MF or eHome directories. Evasive Panda stored MgBot configuration and marker files at these paths as documented by Kaspersky. These specific file and folder combinations indicate MgBot implant activity and staging.

Suspicious HealthApp Batch File Persistence in Start Menu Startup Folder

This rule detects creation of a batch file named after the HealthApp masquerade inside the Start Menu Programs startup folder. The Maverick banking Trojan established persistence by dropping a HealthApp-[GUID].bat file into the user startup location so it re-executes at logon. A batch script placed in the startup folder is a classic autostart persistence mechanism abused to survive reboots.

Suspicious Shai-Hulud GitHub Workflow File Drop (via file_event)

This rule detects creation of a shai-hulud-workflow.yml GitHub Actions workflow file planted by the Shai-Hulud npm worm. The malicious workflow is written into infected repositories to persist and to exfiltrate secrets to attacker infrastructure. The distinctive workflow filename is a reliable artifact of this supply-chain compromise.