Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,224 detections
Filters
Last updated
All Time
Detection languages
1,117
30
19
17
15
Contributors
391
236
131
85
62
Categories
313
252
228
185
166
Platforms
651
437
269
228
200
Products / Services
10,680
9,761
6,694
4,418
3,744
1,224
MITRE Techniques
265
260
234
217
209
CVEs
8
8
6
6
6
IDS Classtypes
2
2
1
1
1
IDS Protocols
2
1
This rule identifies inbound emails that have been delivered to the organization's email domain and are categorized as 'Phishing' by the email security system. It specifically looks for phishing indicators within the email's attachment or body. The query then summarizes the count of such emails by their URL domain, sorting them to highlight the most frequent phishing domains. The accompanying Python script demonstrates how to cross-reference these identified URL domains with VirusTotal for further analysis.
Detects potential GTFOBins abuse on Linux systems where a root shell is spawned by a suspicious parent process (e.g., find, perl, vim, tar, etc.).
This rule relies on DeviceProcessEvents in Microsoft Defender XDR and is intended for environments where Auditd, Sysmon for Linux, or similar native logging is not available.
Note: This detection does not cover all GTFOBins. It focuses specifically on cases where:
- A root-owned shell is spawned
- The parent process is known to be capable of shell escape or privilege abuse
- The child command appears interactive or escape-like
It does not detect:
- Non-shell-based GTFOBin techniques (e.g., file exfiltration via scp, curl, etc.)
- GTFOBin usage that doesn't result in a new shell (e.g., privilege escalation via
misconfigured capabilities)
- Abuse of GTFOBins run under non-root accounts
The query includes logic to detect both high-signal exploitation patterns and suspicious shell spawns, while excluding common false positives (e.g., package post-install scripts and benign environment checks).
This rule relies on DeviceProcessEvents in Microsoft Defender XDR and is intended for environments where Auditd, Sysmon for Linux, or similar native logging is not available.
Note: This detection does not cover all GTFOBins. It focuses specifically on cases where:
- A root-owned shell is spawned
- The parent process is known to be capable of shell escape or privilege abuse
- The child command appears interactive or escape-like
It does not detect:
- Non-shell-based GTFOBin techniques (e.g., file exfiltration via scp, curl, etc.)
- GTFOBin usage that doesn't result in a new shell (e.g., privilege escalation via
misconfigured capabilities)
- Abuse of GTFOBins run under non-root accounts
The query includes logic to detect both high-signal exploitation patterns and suspicious shell spawns, while excluding common false positives (e.g., package post-install scripts and benign environment checks).
This detection specifically flags credentials being added to the Connect Sync Application in Entra ID, a technique known to have persistance from On-premise AD DS to Entra ID. It tries to look at both certificate, client secret, and federated credentials being added, and tries to remove legitimate renewal processes. Since the legitimate renewal process first adds a new certificate only te remove the old one short after, we by default allow for a maximum of 1 minute between the certificate create and delete events.
This rule detects DNS queries to known malicious domains by joining IdentityQueryEvents with ThreatIntelligenceIndicator data. It specifically looks for matches between the queried domain (QueryTarget) and known malicious domains (DomainName) from threat intelligence feeds.
This rule identifies all enabled service accounts in the environment. The goal is to audit the state of service accounts to identify unused or stale accounts, ensure only necessary service accounts are active, reduce the attack surface, and support compliance and security posture assessments. While not directly detecting malicious activity, it provides crucial visibility for security hygiene and can help identify potential accounts that could be abused by adversaries for persistence or defense evasion.
Detects suspicious downloads or fetches of common privilege-escalation tools such as winPEAS, linPEAS, PowerUp, Seatbelt, SharpUp, WinPwn, PrivescCheck, Sherlock, Watson, BeRoot, LinEnum, LSE/LES, Linux Exploit Suggester, pspy, or GTFObins. These tools are often used by adversaries after initial access to enumerate the environment and attempt local privilege escalation.
This might be one of the silliest detections I have created. But since there is a Beacon Object File out there which can be used to directly request Entra ID access tokens from an active beacon on a device using a specific User Agent, we can easily detect this beacon file by flagging the funny user agent and / or scope identifier that is used.
This detection flags any changes happening on the Connect Sync Application in Entra ID. Since this is a very interesting account for attackers to abuse when moving laterally between AD DS and Entra ID, any change to the account should be investigated. We try to exclude legitimate certificate renewal processes, and a new account onboarding in the detection rule.
This rule detects RDP sessions initiated from managed devices to unmanaged devices or devices that do not have a Trusted Platform Module (TPM) enabled or supported. This can pose a security risk, especially when Windows Hello for Business credentials are used, as the keys might not be adequately protected on the destination device.
This rule identifies all service accounts in the environment by querying IdentityInfo logs. The goal is to audit the state of these accounts, helping to identify unused or stale service accounts (especially if disabled), ensure only necessary service accounts are active to reduce the attack surface, and support compliance and security posture assessments. This rule does not detect malicious activity but rather provides an inventory for security auditing.
This detection rule uses a WDAC audit policy to ingest missing DeviceImageLoad events in MDE, and check for suspicious processes using the ncrypt.dll and requesting an Entra ID Nonce. More information on the attack scenario this is detection is applicable for can be found in the references.
This detection rule uses a WDAC audit policy to ingest missing DeviceImageLoad events in MDE, and check for suspicious processes using the ncrypt.dll. More information on the attack scenario this is detection is applicable for can be found in the references.
This detection identifies repeated outbound email events where large files are sent multiple times within a specific time window. It helps uncover potential data exfiltration attempts or misuse of corporate email for transferring large files externally.
Thresholds for file size, frequency, and time window can be adjusted to fit organizational context.
Thresholds for file size, frequency, and time window can be adjusted to fit organizational context.
Detects potential Command and Control (C2) communication patterns based on ASIM-normalized network session data in Microsoft Sentinel. This detection covers three primary patterns:
1) Periodic beaconing with low jitter
2) Long-lived HTTP(S) long-polling sessions
3) Network traffic with very consistent payload sizes
Such patterns can indicate covert communication with compromised systems or malware infections.
1) Periodic beaconing with low jitter
2) Long-lived HTTP(S) long-polling sessions
3) Network traffic with very consistent payload sizes
Such patterns can indicate covert communication with compromised systems or malware infections.
Detects suspicious SMB/NTLM activity triggered by explorer.exe following recent .lnk file creation by script engines. This behavior aligns with the CVE-2025-50154 bypass of Microsoft’s NTLM credential leak patch (CVE-2025-24054), allowing zero-click NTLM hash disclosure and remote binary staging without execution.
Detects when a non-approved application is granted high-risk permissions via consent in Azure AD.
This is a common method for attackers to achieve persistence and privilege escalation in Microsoft 365 environments.
This is a common method for attackers to achieve persistence and privilege escalation in Microsoft 365 environments.
This detection identifies Windows service installations (Event ID 4697) where potentially dangerous permissions like Everyone:Full Control or Authenticated Users:Full Control may be assigned to the service executable.
Such configurations can lead to privilege escalation via service binary hijacking.
Note:
Field index positions in EventData.Data[] may vary depending on the system and must be manually verified using parse_xml(EventData).
This detection requires the following audit subcategory to be enabled:
Audit Policy: Audit Kernel Object (under Object Access)
Such configurations can lead to privilege escalation via service binary hijacking.
Note:
Field index positions in EventData.Data[] may vary depending on the system and must be manually verified using parse_xml(EventData).
This detection requires the following audit subcategory to be enabled:
Audit Policy: Audit Kernel Object (under Object Access)
This detection identifies interactive sign-ins from countries that a user has not accessed from in the past 30 days, based on successful logins. It highlights unusual geographic access patterns, such as remote work via VPNs, possible account compromise, or other travel-related anomalies.
Only interactive sign-ins are included to reduce noise from background service logins and token refreshes.
Recommended Extensions:
1. Trusted Applications Watchlist
Use a Sentinel watchlist (e.g., `TrustedAppsWatchlist`) to maintain known or expected applications (like SAP Cloud Identity Services, Microsoft Teams, Outlook Mobile) that frequently authenticate across multiple countries or devices. This helps suppress expected behavior and avoids alert fatigue.
2. Workation / Remote User Watchlist
Create a watchlist (e.g., `WorkationUsers`) with UPNs or user aliases of employees who are temporarily working abroad or from rotating locations. This allows legitimate, location-shifting activity to be filtered out of alerting, reducing false positives during travel seasons or flexible remote work arrangements.
Only interactive sign-ins are included to reduce noise from background service logins and token refreshes.
Recommended Extensions:
1. Trusted Applications Watchlist
Use a Sentinel watchlist (e.g., `TrustedAppsWatchlist`) to maintain known or expected applications (like SAP Cloud Identity Services, Microsoft Teams, Outlook Mobile) that frequently authenticate across multiple countries or devices. This helps suppress expected behavior and avoids alert fatigue.
2. Workation / Remote User Watchlist
Create a watchlist (e.g., `WorkationUsers`) with UPNs or user aliases of employees who are temporarily working abroad or from rotating locations. This allows legitimate, location-shifting activity to be filtered out of alerting, reducing false positives during travel seasons or flexible remote work arrangements.
Detects the execution of eudcedit.exe, the Windows Private Character Editor, which may be abused to bypass User Account Control (UAC) and achieve privilege escalation. Threat actors can leverage this trusted, auto-elevating binary to execute malicious payloads without prompting the user, particularly when UAC settings are permissive.
Detects DNS queries to domains that are suspiciously similar to trusted ones, which may indicate typosquatting, phishing, or user deception tactics. The detection compares unknown domains to a known safe allowlist using a fuzzy character-difference heuristic.
This detection identifies instances where PowerShell is executed using a legacy engine version (e.g., v2.0), which lacks support for AMSI and script block logging. Attackers often downgrade PowerShell to avoid modern security controls and to evade detection during payload execution.
PowerShell version information is captured from the DeviceEvents table with ActionType `PowerShellEngineVersion`. Any engine version starting with "2." or "1." is treated as suspicious in this detection.
PowerShell version information is captured from the DeviceEvents table with ActionType `PowerShellEngineVersion`. Any engine version starting with "2." or "1." is treated as suspicious in this detection.
Page 49 of 59