Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
985 detections
Filters
Last updated
All Time
Detection languages
640
105
82
64
34
Contributors
242
226
216
58
46
Categories
20,439
11,829
5,873
5,151
4,864
985
Platforms
485
405
224
192
62
Products / Services
416
384
182
109
81
MITRE Techniques
498
497
264
235
234
CVEs
4
4
4
3
3
IDS Classtypes
1
Detects service principal sign-ins involving known compromised application IDs associated with the ConnectWise cloud backup and management supply-chain attack.
Detects successful Azure Active Directory (Entra ID) sign-ins using the device code flow where the originating device is neither registered nor trusted (managed or compliant), which may indicate suspicious authentication attempts or token abuse.
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.
Detects a successful device-code sign-in followed within 60 minutes by non-interactive replay from a different IP AND a persistence action (inbox rule, app consent, device add) from a non-original IP. Persistence is now mandatory (inner join) instead of optional, and the retired AADSignInEventsBeta table is replaced by EntraIdSignInEvents.
Detects a privileged database login brokered through Arcon ARCOS from a source
address without prior history. ARCOS sits in front of database administrative access,
so it observes privileged DB sessions that database-native auditing often misses
entirely.
The extractor exposes a deliberately narrow field set — user, source address and
authentication protocol — so this detection is intentionally simple.
Onboarding: ARCOS-DBEVT is ingested via RDBMS Log Shipper (Bloo extractor 225).
Integration guide: https://bloo.io/docs/integrations
BQL (Bloo Query Language):
stream=authentication where sourcename='ARCOS-DBEVT' and action='LOGIN'
| groupby user, srcip, authproto
address without prior history. ARCOS sits in front of database administrative access,
so it observes privileged DB sessions that database-native auditing often misses
entirely.
The extractor exposes a deliberately narrow field set — user, source address and
authentication protocol — so this detection is intentionally simple.
Onboarding: ARCOS-DBEVT is ingested via RDBMS Log Shipper (Bloo extractor 225).
Integration guide: https://bloo.io/docs/integrations
BQL (Bloo Query Language):
stream=authentication where sourcename='ARCOS-DBEVT' and action='LOGIN'
| groupby user, srcip, authproto
Detects and monitors sign-in events for specific high-privilege or sensitive accounts, such as break-glass accounts, within Microsoft Entra ID.
Detects successful Google Workspace logins from an IP address or user agent not previously seen for the user within a 24-hour window.
Detects successful OAuth device-code flow sign-ins where the user completed multi-factor authentication (MFA) from a non-compliant/unmanaged device using an IP address never seen in their 30-day baseline history. This behavior can indicate device-code phishing or token abuse.
The following analytic detects a process enabling the "SeDebugPrivilege" privilege token. It leverages Windows Security Event Logs with EventCode 4703, filtering out common legitimate processes. This activity is significant because SeDebugPrivilege allows a process to inspect and modify the memory of other processes, potentially leading to credential dumping or code injection. If confirmed malicious, an attacker could gain extensive control over system processes, enabling them to escalate privileges, persist in the environment, or access sensitive information.
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 a successful device-code sign-in whose session is replayed successfully within 60 minutes from a different IP and ASN. Only successful replays count (interrupt codes removed) and Microsoft first-party ASN egress is excluded.
This rule monitors Entra ID Sign-in logs for authentication events flagged by risk detections related to anonymizing infrastructure, such as VPNs, TOR exit nodes, or proxies. It identifies successful logins and aggregate sign-in volume from these IP addresses, flagging successful logins as critical due to the potential for valid account abuse through multi-hop proxy chains.
Detects a successful device-code sign-in followed within 60 minutes by non-interactive replay from a different IP AND a persistence action (inbox rule, app consent, device add) from a non-original IP. Persistence is now mandatory (inner join) instead of optional, and the retired AADSignInEventsBeta table is replaced by EntraIdSignInEvents.
Detects the first-seen external Remote Desktop Protocol (RDP) logon event for a specific user and network provider (ASN) within the last 24 hours, compared against a 14-day historical baseline. This can indicate initial access via compromised credentials or RDP exploitation.
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.
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.
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.
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 a successful device-code sign-in followed within 60 minutes by non-interactive replay from a different IP AND a persistence action (inbox rule, app consent, device add) from a non-original IP. Persistence is now mandatory (inner join) instead of optional, and the retired AADSignInEventsBeta table is replaced by EntraIdSignInEvents.
Detects a successful device-code sign-in followed within 60 minutes by non-interactive replay from a different IP AND a persistence action (inbox rule, app consent, device add) from a non-original IP. Persistence is now mandatory (inner join) instead of optional, and the retired AADSignInEventsBeta table is replaced by EntraIdSignInEvents.
Page 2 of 47