Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
983 detections
Filters
Last updated
All Time
Detection languages
638
105
82
64
34
Contributors
242
226
216
58
46
Categories
20,443
11,831
5,872
5,155
4,866
983
Platforms
483
405
224
192
62
Products / Services
416
383
182
108
81
MITRE Techniques
496
496
263
234
233
CVEs
4
4
4
3
3
IDS Classtypes
1
Detects successful Entra ID sign-ins using the device code authentication flow by users who have no prior device code sign-in history within a 30-day baseline window. This behavior can indicate device code phishing or abuse of the device code grant mechanism.
Detects Microsoft 365 session token replay as described in the Huntress token spray research: sign-ins from the campaign addresses, scripted clients (node or a bare Mozilla/5.0 user agent) using the Office, Authentication Broker or OfficeHome app IDs from an address new to the account, Device Registration Service access from a new address and one session seen from different operating systems and addresses. The campaign address list is short lived and serves as enrichment.
Detects a sequence of events on Linux hosts involving a remote interactive or network logon from an external IP, followed within 5 minutes by root-level process execution, and subsequently within 2 hours by an outbound SSH connection to a private or known attacker IP. Also includes a separate branch for direct logons from known malicious IPs.
Hunting query for the ConnectWise Cloud Backup (SkyKick) application credential abuse reported in October 2026. It returns three signals, sorted by a Priority column. First, sign-ins by the seven ConnectWise and SkyKick application IDs from a public IP address. ConnectWise states the Cloud Backup app normally signs in from Azure private IPv6 addresses. Second, service principals that sign in from a public IP address in a country not seen in their 14-day baseline. This signal evaluates apps with at least 20 prior sign-ins. Third, Entra audit events initiated by applications. These include an application adding itself or another non-user identity to a directory role, an application adding or changing credentials for the first time in the baseline window and any credential change by an application named ConnectWise or SkyKick. Role additions with an unidentified target appear with Review priority. Audit events initiated by applications carry no source IP, so the IP indicator applies to the sign-in signals only. Routine credential changes by Azure services can still appear with Review priority. The query follows the Microsoft Defender advanced hunting schemas and runs without errors in Advanced Hunting. The audit signal was exercised against live Entra audit events in a Microsoft 365 tenant. Indicator columns are short-lived and used for enrichment only.
Hunting query for the ConnectWise Cloud Backup (SkyKick) application credential abuse reported in October 2026. It returns three signals, sorted by a Priority column. First, sign-ins by the seven ConnectWise and SkyKick application IDs from a public IP address. ConnectWise states the Cloud Backup app normally signs in from Azure private IPv6 addresses. Second, service principals that sign in from a public IP address in a country not seen in their 14-day baseline. This signal evaluates apps with at least 20 prior sign-ins. Third, Entra audit events initiated by applications. These include an application adding itself or another non-user identity to a directory role, an application adding or changing credentials for the first time in the baseline window and any credential change by an application named ConnectWise or SkyKick. Role additions with an unidentified target appear with Review priority. Audit events initiated by applications carry no source IP, so the IP indicator applies to the sign-in signals only. Routine credential changes by Azure services can still appear with Review priority. The query follows the Microsoft Defender advanced hunting schemas and runs without errors in Advanced Hunting. The audit signal was exercised against live Entra audit events in a Microsoft 365 tenant. Indicator columns are short-lived and used for enrichment only.
Detects Microsoft Entra ID sign-ins to specific third-party applications related to Updraft (TeamUpdraft, UpdraftCentral, UpdraftVault, UpdraftClone, UpdraftPlus) with anomalous characteristics such as multi-IP access, distinct countries, or failed-then-successful access attempts, indicating possible credential compromise or misuse.
Detects a successful device code flow sign-in followed within one hour by a successful sign-in from the same user using a different IP address and country. This pattern can indicate device code phishing or abuse of the OAuth 2.0 device authorization grant flow.
Detects sign-ins and cloud app events associated with specific compromised vendor application IDs, application names, or a known malicious IP address across Microsoft Entra ID and CloudAppEvents logs.
Detects Entra sign-ins from infrastructure tied to the ConnectWise Cloud Backup (SkyKick) credential abuse: 144.172.64[.]128 (Huntress), plus 144.172.64[.]99 and 144.172.64[.]60 (ConnectWise advisory, Oct 18). Covers service principal sign-ins and user sign-ins, which captures the Oct 13-14 password spray. A success means a token was issued, so treat it as an incident. Failures still show targeting.
Detects a root SSH sign-in from a public IP address or known attacker IP, followed within 30 minutes by a write or modification to the root authorized_keys file on the same device.
Detects sign-in events to Entra ID via service principals where the application is marked as external and enabled, and the user agent string indicates the use of a Python client.
Browser sign-ins and MFA prompts with medium or high sign-in risk from devices that have no Entra device identity and are not managed or compliant. Hunting query, not an alert.
Detects the creation of application-specific passwords followed by their initial use from unknown or new IP addresses using legacy authentication clients, which may indicate account compromise or persistence establishment.
Detects non-interactive service principal sign-ins originating from an IP address and location never seen for that specific principal over a prior 30-day baseline period, approximating potential misuse of stolen cloud credentials exposed via environment variables.
Behavioral hunt for accounts whose non-interactive sign-ins over 30 days are dominated (>=95%) by a single IP using a scripted client (python/aiohttp/httpx/urllib) with no browser. Scripted now requires BOTH no browser AND a scripted user agent, and Microsoft ASN egress is excluded.
Detects known Indicators of Compromise (IOCs) associated with the Ebury Linux backdoor, including specific file hashes, implants like libkeyutils.so.1.10.2, malicious IP connections, and associated network/email artifacts using Microsoft Defender XDR advanced hunting.
Detects successful non-interactive sign-ins by Entra ID service principals from an IP address and location never seen in the prior 14 days, helping to identify potentially compromised application credentials used from unfamiliar locations.
Detects known Indicators of Compromise (IOCs) associated with the Ebury Linux backdoor, including specific file hashes, implants like libkeyutils.so.1.10.2, malicious IP connections, and associated network/email artifacts using Microsoft Defender XDR advanced hunting.
Detects known Indicators of Compromise (IOCs) associated with the Ebury Linux backdoor, including specific file hashes, implants like libkeyutils.so.1.10.2, malicious IP connections, and associated network/email artifacts using Microsoft Defender XDR advanced hunting.
Detects service principal sign-ins involving known compromised application IDs associated with the ConnectWise cloud backup and management supply-chain attack.
Builds a per-account baseline of the devices that each enabled service account has made a successful network logon to over the previous 30 days, then alerts when one makes a successful network logon to a device outside that baseline within the latest window.
Service accounts are identified from IdentityInfo using each account’s most recent recorded type and enabled status, and are matched to logon events by their on-premises SID, so local accounts or accounts in other domains that share the same name are not mistaken for them. Accounts with no logon history in the baseline period are still evaluated, so a dormant service account that suddenly begins making network logons will alert on every device it reaches.
Service accounts tend to touch a small, fixed set of hosts, so a per-entity first-seen check is a strong lateral movement signal with less noise than the same logic applied to users.
Each result is enriched with the number of times the destination device’s sensor reporting restarted during the alert window, along with the times of those restarts in UTC, as restarts close to the new logons often indicate maintenance activity such as patching, although they should prompt a check to confirm rather than closure of the alert.
The rule runs every 24 hours, as this is the only Defender custom detection frequency with a 30-day lookback, and the alert window covers the last 25 hours so that a slightly delayed run does not leave a gap.
The baseline and alert windows are separated by ingestion time rather than event time, so events that arrive late are still evaluated.
Service accounts are identified from IdentityInfo using each account’s most recent recorded type and enabled status, and are matched to logon events by their on-premises SID, so local accounts or accounts in other domains that share the same name are not mistaken for them. Accounts with no logon history in the baseline period are still evaluated, so a dormant service account that suddenly begins making network logons will alert on every device it reaches.
Service accounts tend to touch a small, fixed set of hosts, so a per-entity first-seen check is a strong lateral movement signal with less noise than the same logic applied to users.
Each result is enriched with the number of times the destination device’s sensor reporting restarted during the alert window, along with the times of those restarts in UTC, as restarts close to the new logons often indicate maintenance activity such as patching, although they should prompt a check to confirm rather than closure of the alert.
The rule runs every 24 hours, as this is the only Defender custom detection frequency with a 30-day lookback, and the alert window covers the last 25 hours so that a slightly delayed run does not leave a gap.
The baseline and alert windows are separated by ingestion time rather than event time, so events that arrive late are still evaluated.
Page 1 of 47