Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
3,750 detections
Filters
Last updated
All Time
Detection languages
2,544
328
307
253
149
Contributors
953
720
641
297
173
Categories
1,245
994
880
773
476
Platforms
2,850
1,449
1,229
356
73
Products / Services
10,683
9,759
6,695
4,421
3,750
MITRE Techniques
1,096
989
950
912
820
CVEs
17
6
2
1
1
IDS Classtypes
9
4
3
2
2
IDS Protocols
21
1
Detects Microsoft 365 access attempts where the ClientAppId masquerades as Microsoft Office (d3590ed6-52b3-4102-aeff-aad2292ab01c) to bypass conditional access policies, but the UserAgent string reveals the use of a programmatic script (e.g., Python, PowerShell). This mismatch is a known tactic utilized by UNC6671 (BlackFile) during automated data exfiltration operations.
SharePoint Online Sensitive Data Search
Cortex XDR
This rule detects when users perform search queries in SharePoint Online that contain keywords indicative of sensitive data. The rule categorizes these searches into several types: credentials, personnel/HR information, infrastructure reconnaissance, financial/PII, and confidential business information.
Tycoon2FA Known Infrastructure Detection
Cortex XDR
This rule detects suspicious sign-in attempts to Microsoft 365 accounts that originate from known Tycoon2FA infrastructure. It specifically looks for device code flow authentications from IP addresses and Autonomous System Numbers (ASNs) associated with Tycoon2FA, combined with indicators like unmanaged/non-compliant devices, specific user agent patterns (axios, node, undici), and particular application IDs, and an unbound sign-in token protection status. This combination of indicators suggests an attempt to hijack Microsoft 365 accounts using device code phishing.
Detects programmatic file access in Microsoft 365/SharePoint environments where the operation is logged as 'FileAccessed' but the UserAgent indicates a scripting library like python-requests or PowerShell. This behavior is indicative of data exfiltration techniques used by actors like UNC6671 (BlackFile) who stream file content directly to bypass traditional 'FileDownloaded' monitoring.
Detects possible Adversary-in-the-Middle (AiTM) attacks, session cookie replay, MFA session hijacking, token theft, and stolen cloud session reuse by identifying abnormal SessionId reuse across multiple IPs, browsers, and devices. This detection compares current session activity against a 14-day historical user behavior baseline to identify new or abnormal behavior. It includes risk scoring and account classification, while reducing false positives from token refresh activity and common Microsoft Teams noise.
This rule tracks user and administrator submissions of potential phishing emails to Microsoft for analysis within the Security & Compliance Center. It extracts and logs details such as the submission verdict, rescan verdict, recipients, subject, content, submitter's display name, sender information (P1 and P2), email destination, final delivery verdict, and sender IP address. This provides visibility into an organization's proactive efforts to report and analyze suspected phishing attempts.
High Email Volume to Personal Accounts
Cortex XDR
Detects potential data exfiltration or policy violation by identifying users sending a high volume of emails, large emails, or emails to many unique personal email addresses (e.g., Gmail, Yahoo, Outlook.com) from an Office 365 Exchange Online mailbox. This rule aggregates email activity by sender and flags if any of the defined thresholds are met: total sent data to personal addresses exceeds 25 MB, total messages sent to personal addresses exceeds 10, emails sent to more than 5 unique personal addresses, or any single message sent to a personal address exceeds 25 MB. This is designed to be ran as a scheduled correlation for a day time frame. Thresholds can also be configured to fit your environment. Each user will have a different line that contains all of the matching emails they sent to, the attachments, and subjects of the emails.
SharePoint Online Sensitive Data Search
Cortex XDR
This rule detects when users perform search queries in SharePoint Online that contain keywords indicative of sensitive data. The rule categorizes these searches into several types: credentials, personnel/HR information, infrastructure reconnaissance, financial/PII, and confidential business information.
Creating multiple detections without reviewing them over time to ensure they’re still effective can easily turn them into pure noise, adding nothing but fatigue to our day-to-day incident analysis.
The DOVE Model (Detection Overlap & Value Evaluation) evaluates detections across four main dimensions (https://zenodo.org/records/20011459):
1. Detection Type
IOC-based detections tend to have a shorter lifecycle, current TI sources are collecting a huge number of indicators based on new attack or threats which present a higher duplication risk.
IOA-based detections focus on behaviors, have a longer lifecycle, provide higher unique value and requires extended time to create corresponding detection.
2. System / Technology Coverage
Mainstream technologies (e.g., Windows, M365, macOS) are heavily monitored and widely covered by SIEM platforms, increasing duplication probability.
Non-mainstream or custom systems offer less coverage and therefore provide opportunities for more unique detections.
3. Threat Recency
Older or well-known threats are widely documented and likely already covered by existing detections.
New or emerging threats are less likely to be covered, reducing duplication risk and increasing detection value.
4. Source / Provider
Built-in or native detections are already integrated into SIEM platforms and often overlap with custom logic.
Custom or third-party detections introduce tailored logic and reduce overlap probability.
The following KQL query can evaluate how useful are our current detections with the aim to detect alerts that are showing the same assets within the same hour, which indicates potential overlap.
Custom detections added in current SIEM or XDR solutions can easily turn from useful detections into noise, so analyzing their results is crucial.
The DOVE Model (Detection Overlap & Value Evaluation) evaluates detections across four main dimensions (https://zenodo.org/records/20011459):
1. Detection Type
IOC-based detections tend to have a shorter lifecycle, current TI sources are collecting a huge number of indicators based on new attack or threats which present a higher duplication risk.
IOA-based detections focus on behaviors, have a longer lifecycle, provide higher unique value and requires extended time to create corresponding detection.
2. System / Technology Coverage
Mainstream technologies (e.g., Windows, M365, macOS) are heavily monitored and widely covered by SIEM platforms, increasing duplication probability.
Non-mainstream or custom systems offer less coverage and therefore provide opportunities for more unique detections.
3. Threat Recency
Older or well-known threats are widely documented and likely already covered by existing detections.
New or emerging threats are less likely to be covered, reducing duplication risk and increasing detection value.
4. Source / Provider
Built-in or native detections are already integrated into SIEM platforms and often overlap with custom logic.
Custom or third-party detections introduce tailored logic and reduce overlap probability.
The following KQL query can evaluate how useful are our current detections with the aim to detect alerts that are showing the same assets within the same hour, which indicates potential overlap.
Custom detections added in current SIEM or XDR solutions can easily turn from useful detections into noise, so analyzing their results is crucial.
MC1293480: https://admin.cloud.microsoft/?ref=MessageCenter/:/messages/MC1293480
This rule detects the creation or modification of Exchange inbox rules with highly suspicious or obfuscated names. Adversaries often create inbox rules with short, non-descriptive, or special character names (e.g., '.', '...', ';') to forward, redirect, or delete emails, facilitating data exfiltration or maintaining persistence. The rule specifically looks for rule names that are very short (less than 3 characters), empty, or match a predefined list of suspicious names.
Identifies emails spoofing NIPR, NAIC, or Stripe domains with invoice-related lures that fail authentication. This rule specifically looks for emails where the sender's domain (SenderFromDomain or SenderMailFromDomain) is one of the targeted domains (nipr.com, naic.org, stripe.com), the subject contains keywords like 'invoice' or 'past due', and the email authentication details do not indicate a 'pass'. This combination suggests a phishing attempt leveraging brand impersonation and financial urgency.
This rule detects successful sign-ins to specific Microsoft 365 applications (identified by ApplicationId '08ad6f98-a4f8-4635-bb8d-f1a3044760f0' or '07c030f6-5743-41b7-ba00-0a6e85f37c17') from devices that have previously established a network connection with a process named 'cowork-svc'. The rule correlates network connection events with Azure AD sign-in events over a 30-day lookback period to identify potentially legitimate or suspicious activity related to 'cowork-svc' application usage.
This rule detects suspicious activity where a user clicks on a URL from an email and subsequently accesses a '.workers.dev' domain that contains keywords commonly associated with credential harvesting or malicious activity (e.g., 'docusign', 'onedrive', 'password_reset'). This pattern often indicates a phishing attempt where an attacker uses a Cloudflare Workers domain to host a malicious landing page.
This rule detects anomalous mass device wipe or deletion activity in Microsoft Intune by comparing current activity against an actor's historical behavior. It identifies four patterns: first-time wipers with high volume, known actors statistically far above their norm (Z-score), thin-history actors exceeding their personal peak, and time-compressed bursts of wipes. The rule calculates a severity based on the volume and rate of wipes.
This rule detects when a device wipe or delete operation is performed via Microsoft Intune. It specifically looks for 'wipe ManagedDevice' or 'Delete ManagedDevice' operations in Intune audit logs within the last 24 hours. The rule is designed to be correlated with other alerts by filtering on a specific ActorUPN, indicating a potential malicious mass device wipe attack.
This rule detects attempts to perform a mass device wipe or deletion using Microsoft Intune. It identifies devices that have been wiped or deleted within the last 24 hours and enriches this information with device details such as name, user, OS, and ownership. This can indicate a destructive attack or an attempt to remove evidence.
Detects the creation or modification of Power Automate flows that connect to external services commonly used for data exfiltration or command and control, such as webhooks, Gmail, Dropbox, Google Drive, Slack, RSS feeds, custom connectors, or generic HTTP requests/webhooks. This could indicate an adversary attempting to establish persistence or exfiltrate data from the Power Platform environment.
Detects the creation of new connectors in Power Automate (formerly Microsoft Flow) that establish connections to external services. This activity is identified by monitoring 'PutConnection' operations within PowerPlatform or MicrosoftFlow audit logs. Such an event could indicate an adversary attempting to integrate malicious services or exfiltrate data.
Detects suspicious modifications to Power Automate flow permissions, including sharing flows or changing role assignments. This could indicate a compromised account attempting to gain unauthorized access or persistence within the Power Platform environment.
If you are in a country where there is more than one local language, like me in Switzerland, it is challenging to create detections based on subjects because you can have them in multiple languages. Therefore, focusing on the value odspnotify inside of InternetMessageId - which does not change based on the language - helps to detect cases.
This one is related to OneTimePassCode and is useful to identify if the code is sent to other domains, which could mean that a forwarding rule has been configured or some other suspicious activity.
This one is related to OneTimePassCode and is useful to identify if the code is sent to other domains, which could mean that a forwarding rule has been configured or some other suspicious activity.
Page 133 of 179