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
'This query detects authentication attempt from a fake computer account(username ends with $).
Computer accounts are normally not authenticating via interactive logon or remote desktop neither they are unlocking the systems.
Ref: https://blog.menasec.net/2019/02/threat-hunting-6-hiding-in-plain-sights.html'
Computer accounts are normally not authenticating via interactive logon or remote desktop neither they are unlocking the systems.
Ref: https://blog.menasec.net/2019/02/threat-hunting-6-hiding-in-plain-sights.html'
'Summarizes uses of uncommon & undocumented commandline switches to create persistence
User accounts may be created to achieve persistence on a machine.
Read more here: https://attack.mitre.org/wiki/Technique/T1136
Query for users being created using "net user" command
"net user" commands are noisy, so needs to be joined with another signal -
e.g. in this example we look for some undocumented variations (e.g. /ad instead of /add)'
User accounts may be created to achieve persistence on a machine.
Read more here: https://attack.mitre.org/wiki/Technique/T1136
Query for users being created using "net user" command
"net user" commands are noisy, so needs to be joined with another signal -
e.g. in this example we look for some undocumented variations (e.g. /ad instead of /add)'
' Identifies measureable increase in successful sign-ins from user accounts.
Spike is determined based on Time series anomaly which will look at historical baseline values.
Ref : https://docs.microsoft.com/azure/active-directory/fundamentals/security-operations-user-accounts#monitoring-for-successful-unusual-sign-ins'
Spike is determined based on Time series anomaly which will look at historical baseline values.
Ref : https://docs.microsoft.com/azure/active-directory/fundamentals/security-operations-user-accounts#monitoring-for-successful-unusual-sign-ins'
This query calculates device uptime based on periodic DeviceInfo which is recorded every 15 minutes regardless of device's network connectivity and uploaded once device gets online. If its interval is over 16 minutes, we can consider device is turned off.Calculated uptime may include up to 30 minutes gap. Devices may be turned on up to 15 minutes earlier than the "timestamp", and may be turned off up to 15 minutes later than the "LastTimestamp". When the single independent DeviceInfo without any sequential DeviceInfo within 16 minutes before or after is recorded, "DurationAtLeast" will be displayed as "00.00:00:00".
'Identifies when 100 or more failed attempts by a given user in 10 minutes occur on the IIS Server.
This could be indicative of attempted brute force based on known account information.
This could also simply indicate a misconfigured service or device.
References:
IIS status code mapping - https://support.microsoft.com/help/943891/the-http-status-code-in-iis-7-0-iis-7-5-and-iis-8-0
Win32 Status code mapping - https://msdn.microsoft.com/library/cc231199.aspx'
This could be indicative of attempted brute force based on known account information.
This could also simply indicate a misconfigured service or device.
References:
IIS status code mapping - https://support.microsoft.com/help/943891/the-http-status-code-in-iis-7-0-iis-7-5-and-iis-8-0
Win32 Status code mapping - https://msdn.microsoft.com/library/cc231199.aspx'
'Identifies when failed logon attempts are 20 or higher during a 10 minute period (2 failed logons per minute minimum) from valid account.'
Device Logons from Unknown IP Addresses.
This query identifies device logons from IP addresses not associated with any machine in Defender ATP.
This query identifies device logons from IP addresses not associated with any machine in Defender ATP.
This query looks for events that are near in time to a detected event.
It shows how you could avoid typing exact timestamps, and replace it with a simple query to get the timestamp of your pivot event (e.g. a detected event).
This is useful when you have queries that you run often - e.g. as part of your regular investigation of an alert.
Original query: filter for network logon events right before some timestamp.
It shows how you could avoid typing exact timestamps, and replace it with a simple query to get the timestamp of your pivot event (e.g. a detected event).
This is useful when you have queries that you run often - e.g. as part of your regular investigation of an alert.
Original query: filter for network logon events right before some timestamp.
This query looks for events that are near in time to a detected event.
It shows how you could avoid typing exact timestamps, and replace it with a simple query to get the timestamp of your pivot event (e.g. a detected event).
This is useful when you have queries that you run often - e.g. as part of your regular investigation of an alert.
Original query: filter for network logon events right before some timestamp.
It shows how you could avoid typing exact timestamps, and replace it with a simple query to get the timestamp of your pivot event (e.g. a detected event).
This is useful when you have queries that you run often - e.g. as part of your regular investigation of an alert.
Original query: filter for network logon events right before some timestamp.
This query looks for events that are near in time to a detected event.
It shows how you could avoid typing exact timestamps, and replace it with a simple query to get the timestamp of your pivot event (e.g. a detected event).
This is useful when you have queries that you run often - e.g. as part of your regular investigation of an alert.
Original query: filter for network logon events right before some timestamp.
It shows how you could avoid typing exact timestamps, and replace it with a simple query to get the timestamp of your pivot event (e.g. a detected event).
This is useful when you have queries that you run often - e.g. as part of your regular investigation of an alert.
Original query: filter for network logon events right before some timestamp.
This query looks for events that are near in time to a detected event.
It shows how you could avoid typing exact timestamps, and replace it with a simple query to get the timestamp of your pivot event (e.g. a detected event).
This is useful when you have queries that you run often - e.g. as part of your regular investigation of an alert.
Original query: filter for network logon events right before some timestamp.
It shows how you could avoid typing exact timestamps, and replace it with a simple query to get the timestamp of your pivot event (e.g. a detected event).
This is useful when you have queries that you run often - e.g. as part of your regular investigation of an alert.
Original query: filter for network logon events right before some timestamp.
Sample query to detect If there are more then 3 failed logon authentications on high value assets.
Update DeviceName to reflect your high value assets.
For questions @MiladMSFT on Twitter or milad.aslaner@microsoft.com.
Update DeviceName to reflect your high value assets.
For questions @MiladMSFT on Twitter or milad.aslaner@microsoft.com.
Under some circumstances it is only allowed that users
from country X logon to devices from country X.
This query finds logon from users from other countries than X.
The query requires a property to identify the users from
country X. In this example a specific Email Address.
from country X logon to devices from country X.
This query finds logon from users from other countries than X.
The query requires a property to identify the users from
country X. In this example a specific Email Address.
Looks for a new device registration in Entra ID preceded by medium or high-risk sign-in session for the same user within maximum 6h timeframe.
Endpoint Inventory
This rule detects successful user logins where the user's termination date is in the past, indicating a login from a terminated employee. This could signify unauthorized access or a failure in account deprovisioning processes. The rule requires a context data source that provides user termination dates, such as Azure AD Context or Workday.
This rule detects attempts to access the Active Directory contact object to read the AD FS Distributed Key Manager (DKM) master key value. This activity is identified by monitoring Windows Security Event ID 4662 (An operation was performed on an object) for specific property GUIDs associated with the DKM master key, combined with a successful user login event (Event ID 4624) from the same host within a 5-minute window. This indicates a potential attempt to compromise AD FS for credential theft or persistence.
This rule detects the use of PowerShell to enumerate successful logon events (Event ID 4624) from the security event log on a Windows host. It specifically looks for command-line executions containing 'Get-EventLog', 'security', and '-instanceid 4624'. This activity is often performed during the reconnaissance phase by adversaries to understand user activity on a system.
Detect multiple user logins from multiple states or countries using Chronicle GeoIP enrichment.
Allowed Logins from Terminated Employees
Detect Multiple Failed Login Attempts followed by Successful Login
Page 45 of 47