Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
29 detections
Filters
Last updated
All Time
Detection languages
27
2
Contributors
13
11
2
1
1
Categories
25
16
11
5
5
Platforms
22
6
1
1
1
Products / Services
11
10
7
2
2
MITRE Techniques
18,110
15,627
12,575
8,387
6,212
CVEs
1
This rule detects successful or failed logon attempts originating from IP addresses identified by threat intelligence as associated with botnets, command and control (C2) infrastructure, or proxies. The rule specifically looks for 'LogOn' or 'FailedLogOn' activity types where the source IP's threat intelligence indicator type is 'Botnet', 'C2', or 'Proxy', and where activity insights are available.
This rule detects interactive logons (LogonType 10) where a single account from the same domain logs into multiple distinct devices. This could indicate an attacker using compromised credentials to move laterally within the network or access multiple systems.
This rule detects successful or failed logon attempts originating from IP addresses identified by threat intelligence as associated with botnets, command and control (C2) infrastructure, or proxies. The rule specifically looks for 'LogOn' or 'FailedLogOn' activity types where the source IP's threat intelligence indicator type is 'Botnet', 'C2', or 'Proxy', and where activity insights are available.
This rule detects interactive logons (LogonType 10) where a single account from the same domain logs into multiple distinct devices. This could indicate an attacker using compromised credentials to move laterally within the network or access multiple systems.
This rule detects unusual logon activity for service accounts. It identifies service accounts by looking for a dollar sign ($) at the end of the username. The rule then counts logons, unique IP addresses, and unique computers for these service accounts within one-hour bins. An alert is triggered if a service account has 10 or more logons or logs in from 5 or more unique IP addresses within that hour, indicating potential abuse or compromise.
This rule detects unusual logon activity for service accounts. It identifies service accounts by looking for a dollar sign ($) at the end of the username. The rule then counts logons, unique IP addresses, and unique computers for these service accounts within one-hour bins. An alert is triggered if a service account has 10 or more logons or logs in from 5 or more unique IP addresses within that hour, indicating potential abuse or compromise.
This rule detects unusual logon activity for service accounts. It identifies service accounts by looking for a dollar sign ($) at the end of the username. The rule then counts logons, unique IP addresses, and unique computers for these service accounts within one-hour bins. An alert is triggered if a service account has 10 or more logons or logs in from 5 or more unique IP addresses within that hour, indicating potential abuse or compromise.
This rule detects suspicious NTLM network or remote interactive logon activity. It specifically looks for multiple distinct accounts logging in from the same device and remote IP address within a one-hour window, using NTLM authentication via NtLmSsp or Seclogon processes. This pattern can indicate credential stuffing, NTLM relay attacks, or other forms of credential misuse.
This rule detects suspicious NTLM network or remote interactive logon activity. It specifically looks for multiple distinct accounts logging in from the same device and remote IP address within a one-hour window, using NTLM authentication via NtLmSsp or Seclogon processes. This pattern can indicate credential stuffing, NTLM relay attacks, or other forms of credential misuse.
Detects instances where the telnetd process spawns the login binary with the '-f' flag. This behavior is indicative of exploitation of CVE-2026-24061, which allows an attacker to bypass authentication by injecting arguments into the login process via a crafted USER environment variable.
This rule detects interactive logons (LogonType 10) where a single account from the same domain logs into multiple distinct devices. This could indicate an attacker using compromised credentials to move laterally within the network or access multiple systems.
This rule detects interactive console logons (LogonType 2) to server systems and domain controllers. It specifically looks for successful (EventID 528, 4624) and failed (EventID 529, 4625) interactive logon attempts. The rule filters out events where the logon process name is 'Advapi' and the computer is a workstation, aiming to reduce false positives from legitimate workstation activities.
This rule detects successful or failed logon attempts originating from IP addresses identified by threat intelligence as associated with botnets, command and control (C2) infrastructure, or proxies. The rule specifically looks for 'LogOn' or 'FailedLogOn' activity types where the source IP's threat intelligence indicator type is 'Botnet', 'C2', or 'Proxy', and where activity insights are available.
This rule identifies all logon events within the organization's domain by querying the IdentityLogonEvents table. It extracts distinct account display names, UPNs, device names, destination device names, action types, account domains, and applications involved in the logon.
KQL Query
'This content is employed to correlate with Microsoft Defender XDR phishing-related alerts. It focuses on instances where a user successfully connects to a phishing URL from a non-Microsoft network device and subsequently makes successful sign-in attempts from the phishing IP address.'
Baseline Comparison.
Author: miflower.
The purpose of this query is to perform a comparison between "known good" machines and suspected bad machines.
The original concept for this query was born due to reapplying the same 'whitelist' filters over and over.
It brings deltas between a baseline and another machine quickly to the analyst's view.
This query supports multiple suspected bad machines and multiple "known good" machines.
It also supports providing a timeframe for how far back in time to build a baseline as well as how far back in time to evaluate the suspected bad machines.
Each of the links provided by DeviceId/DeviceName will go to the most recent entry for whatever entity is listed.
Average results for the pre-defined settings below with a single good host and a single bad host on a 'huge' tenant (300k+ machines):.
Compute Time: ~10-20 seconds.
Result Set Size: ~500 rows.
The workflow is as follows:.
1. Establish Variables that are editable on a per-query basis.
2. Define functions for reuse.
3. Calculate DeviceIds for all machines in scope.
4. Derive deltas using the aforementioned functions.
5. Union together all results into a single view.
The following datasets are returned:.
1. Alerts on the suspected bad machines (ignores known good machines, because...they're alerts, additional data has the triggered file).
2. Connected Networks (from DeviceNetworkInfo table, additional data has full Connected Network details).
3. File Creations (disabled by default due to volume, enable at your own risk, additional data has initiating processes).
4. Image Loads (disabled by default due to volume, enable at your own risk, additional data has initiating processes).
5. Logon (derived from DeviceLogonEvents for the unique users logged on, additional data has logon types).
6. Network communication (grouped by 2nd level-domain, ie 'microsoft.com' in 'www.microsoft.com' and 'web.microsoft.com', additional data has the full list of URLs).
7. Process creation (additional da
Author: miflower.
The purpose of this query is to perform a comparison between "known good" machines and suspected bad machines.
The original concept for this query was born due to reapplying the same 'whitelist' filters over and over.
It brings deltas between a baseline and another machine quickly to the analyst's view.
This query supports multiple suspected bad machines and multiple "known good" machines.
It also supports providing a timeframe for how far back in time to build a baseline as well as how far back in time to evaluate the suspected bad machines.
Each of the links provided by DeviceId/DeviceName will go to the most recent entry for whatever entity is listed.
Average results for the pre-defined settings below with a single good host and a single bad host on a 'huge' tenant (300k+ machines):.
Compute Time: ~10-20 seconds.
Result Set Size: ~500 rows.
The workflow is as follows:.
1. Establish Variables that are editable on a per-query basis.
2. Define functions for reuse.
3. Calculate DeviceIds for all machines in scope.
4. Derive deltas using the aforementioned functions.
5. Union together all results into a single view.
The following datasets are returned:.
1. Alerts on the suspected bad machines (ignores known good machines, because...they're alerts, additional data has the triggered file).
2. Connected Networks (from DeviceNetworkInfo table, additional data has full Connected Network details).
3. File Creations (disabled by default due to volume, enable at your own risk, additional data has initiating processes).
4. Image Loads (disabled by default due to volume, enable at your own risk, additional data has initiating processes).
5. Logon (derived from DeviceLogonEvents for the unique users logged on, additional data has logon types).
6. Network communication (grouped by 2nd level-domain, ie 'microsoft.com' in 'www.microsoft.com' and 'web.microsoft.com', additional data has the full list of URLs).
7. Process creation (additional da
This query identifies files that are copied to a device over SMB, then executed within a
specified threshold. Default is 5 seconds, but is configurable by tweaking the value for
ToleranceInSeconds.
specified threshold. Default is 5 seconds, but is configurable by tweaking the value for
ToleranceInSeconds.
Query #1: Look for public IP addresses that failed to logon to a computer multiple times, using multiple accounts, and eventually succeeded.
'Detects a successful logon by a privileged account from an ASN not logged in from in the last 14 days.
Monitor these logons to ensure they are legitimate and identify if there are any similar sign ins.'
Monitor these logons to ensure they are legitimate and identify if there are any similar sign ins.'
Identify accounts that have logged on to affected endpoints.
Check for specific alerts.
Check for specific alerts.
Page 1 of 2