Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
18 detections
Filters
Last updated
All Time
Detection languages
8
7
3
Contributors
8
3
2
2
2
Categories
17
4
3
3
2
Platforms
18
Products / Services
5
3
3
3
1
MITRE Techniques
18,114
15,633
12,576
8,388
6,214
CVEs
1
1
1
Detects the loading of the 'wsftprm.sys' driver, which has been associated with CVE-2023-52271 and abused by ransomware groups to terminate security processes. This rule specifically looks for 'wsftprm.sys' in DeviceImageLoadEvents.
Detects suspicious patterns of driver loading activity, specifically looking for multiple driver load attempts (sc create, sc start, net start, wmic service) involving .sys, kernel, or driver files from non-System32 directories or within the Temp directory. This pattern can indicate an attempt to install a rootkit or other malicious kernel-mode software.
Detects suspicious patterns of driver loading activity, specifically looking for multiple driver load attempts (sc create, sc start, net start, wmic service) involving .sys, kernel, or driver files from non-System32 directories or within the Temp directory. This pattern can indicate an attempt to install a rootkit or other malicious kernel-mode software.
This rule detects the loading of known malicious drivers by their file names. Adversaries often use malicious drivers for persistence, privilege escalation, or to evade defenses. The rule specifically looks for a predefined list of driver filenames that have been identified as malicious or associated with vulnerable drivers exploited by attackers. This detection is based on the 'ImageLoaded' field, which indicates when a driver is loaded into the system.
Detects attempts to load drivers that have been revoked by Microsoft, as indicated by EventID 3023 in the CodeIntegrity-Operational log. This event signifies that the Windows Code Integrity component has blocked a driver from loading due to its revoked certificate status, which is a critical security measure to prevent malicious or vulnerable drivers from executing on the system.
Detects the load of the WinRing0 driver, which is known to be vulnerable and has been exploited by threat actors, crypto miners (like XMRIG), and other malware for privilege escalation. The detection is based on specific file names or a known IMPHASH associated with the driver.
Detects the loading of the System Informer tool's driver, 'SystemInformer.sys', by checking for its file name or specific SHA256 hashes. System Informer is a legitimate system monitoring tool that can be used by adversaries for reconnaissance or to gain deeper system insights, making its driver load a potential indicator of compromise or unauthorized activity.
Detects the load of HackSys Extreme Vulnerable Driver (HEVD.sys), an intentionally vulnerable Windows driver often abused by threat actors for privilege escalation and other malicious activities. The rule identifies the driver by its filename and known IMPHASH values.
This rule detects the usage of the 'SeLoadDriverPrivilege' privilege, which is necessary to load or unload device drivers. This privilege allows a user to dynamically load and unload kernel-mode code, excluding Plug and Play device drivers. The rule aims to identify potentially malicious kernel driver loading by filtering out known legitimate processes and tools. It specifically mentions detecting tools like Ghost-In-The-Logs and Sysinternals, indicating that a whitelist approach is required to reduce false positives.
KQL Query
KQL Query from file: Threat Hunting BYOVD Scenarios
Expanding on DeviceEvents output with Attack Surface Reduction (ASR) rule descriptions.
The ActionType values of the ASR events already explain what rule was matched and if it was audited or blocked.
However, it could still be useful to have a more human-friendly description in the results.
Also, this query is a good example for how you could define your own lookup tables and join with them.
The events in the DeviceEvents table contain a GUID for the various ASR rules rather than a full description of the rule.
This query will create a table which has the description for each ASR rule as per https://docs.microsoft.com/windows/security/threat-protection/windows-defender-exploit-guard/enable-attack-surface-reduction.
This table is then joined to the output of a query against the DeviceEvents table and shows a summary count of the events by the newly defined description.
This query shows the ability to use joins and custom dimension tables.
See https://docs.loganalytics.io/docs/Language-Reference/Tabular-operators/join-operator for more information on the join syntax.
For more questions on this query, feel free to ping @FlyingBlueMonki on twitter or mattegen@microsoft.com via email.
First lets start by creating a table of the rule descriptions to rule guids.
The ActionType values of the ASR events already explain what rule was matched and if it was audited or blocked.
However, it could still be useful to have a more human-friendly description in the results.
Also, this query is a good example for how you could define your own lookup tables and join with them.
The events in the DeviceEvents table contain a GUID for the various ASR rules rather than a full description of the rule.
This query will create a table which has the description for each ASR rule as per https://docs.microsoft.com/windows/security/threat-protection/windows-defender-exploit-guard/enable-attack-surface-reduction.
This table is then joined to the output of a query against the DeviceEvents table and shows a summary count of the events by the newly defined description.
This query shows the ability to use joins and custom dimension tables.
See https://docs.loganalytics.io/docs/Language-Reference/Tabular-operators/join-operator for more information on the join syntax.
For more questions on this query, feel free to ping @FlyingBlueMonki on twitter or mattegen@microsoft.com via email.
First lets start by creating a table of the rule descriptions to rule guids.
This analytic identifies drivers being loaded across the fleet by leveraging a PowerShell script to capture driver data. It helps monitor for unauthorized or malicious drivers that could compromise system integrity, execute arbitrary code, escalate privileges, or maintain persistence within the environment.
Monitor for creation of suspicious files in the /spools/driver/ folder. This is a broad-based search that will surface any creation or modification of files in the folder targeted by this exploit. False Positives for legitimate driver activity (when that activity should be present) in this folder are possible
The analytic detects the loading of known vulnerable Windows drivers, which may indicate potential persistence or privilege escalation attempts. It leverages Sysmon EventCode 6 to identify driver loading events and cross-references them with a list of vulnerable drivers. This activity is significant as attackers often exploit vulnerable drivers to gain elevated privileges or maintain persistence on a system. If confirmed malicious, this could allow attackers to execute arbitrary code with high privileges, leading to further system compromise and potential data exfiltration.
This analytic detects the creation of new .sys files on disk. It leverages the Endpoint.Filesystem data model to identify and log instances where .sys files are written to the filesystem. This activity is significant because .sys files are often used as kernel mode drivers, and their unauthorized creation can indicate malicious activity such as rootkit installation. If confirmed malicious, this could allow an attacker to gain kernel-level access, leading to full system compromise, persistent control, and the ability to bypass security mechanisms.
This rule detects when a driver is loaded from a temporary directory. Adversaries may load malicious drivers from temporary locations as part of persistence, privilege escalation, or defense evasion techniques. Loading drivers from temporary directories is often an unusual behavior for legitimate system operations and can indicate suspicious activity.
Detects the loading of a kernel driver that has been revoked by Code Integrity. This indicates an attempt to load a driver that is no longer trusted, potentially for malicious purposes or due to a known vulnerability. Event ID 3021 signifies a revoked driver load, while 3022 indicates a revoked driver load allowed due to a kernel mode debugger being attached.