Adversaries may use custom or malicious DLLs to execute code stealthily within a system. SOC teams should proactively hunt for this behavior in Azure Sentinel to identify potential lateral movement or persistence mechanisms that evade traditional detection.
YARA Rule
rule Check_Dlls
{
meta:
Author = "Nick Hoffman"
Description = "Checks for common sandbox dlls"
Sample = "de1af0e97e94859d372be7fcf3a5daa5"
strings:
$dll1 = "sbiedll.dll" wide nocase ascii fullword
$dll2 = "dbghelp.dll" wide nocase ascii fullword
$dll3 = "api_log.dll" wide nocase ascii fullword
$dll4 = "dir_watch.dll" wide nocase ascii fullword
$dll5 = "pstorec.dll" wide nocase ascii fullword
$dll6 = "vmcheck.dll" wide nocase ascii fullword
$dll7 = "wpespy.dll" wide nocase ascii fullword
condition:
2 of them
}
This YARA rule can be deployed in the following contexts:
This rule contains 7 string patterns in its detection logic.
Scenario: Legitimate DLL file updates via Windows Update
Filter/Exclusion: file.name contains "WindowsUpdate" or file.hash in known Windows Update DLL hashes
Scenario: Scheduled Task running a legitimate .dll file
Filter/Exclusion: process.name contains "schtasks.exe" or process.parent.name contains "Task Scheduler"
Scenario: Admin using Process Monitor to inspect DLL loading
Filter/Exclusion: process.name contains "procmon.exe" or process.user contains "SYSTEM"
Scenario: Antivirus or endpoint protection scanning DLLs
Filter/Exclusion: process.name contains "mpsvc.exe" or process.name contains "mpengine.exe"
Scenario: PowerShell script loading a signed DLL for automation
Filter/Exclusion: process.name contains "powershell.exe" and file.signature is signed or file.publisher contains "Microsoft"