Christopher Scott
@ScochaNewcastle upon TyneCompletionist
0 followers18 downloads223 copies7 likes1,199 views
54 detections
Filters
Last updated
All Time
Detection languages
33
20
1
Categories
22
22
9
8
7
Platforms
27
17
7
2
2
Products / Services
21
10
7
5
4
MITRE Techniques
20
12
6
6
6
This detection flags a parent and child process pair on internet-facing Windows servers, where the parent is a web server process and the child is the process it launched. The web server processes covered are w3wp, httpd, nginx and Tomcat, including versioned Tomcat service executables such as tomcat9.exe and Tomcat running under java.exe, which is identified by the Catalina bootstrap class in its command line. A server is treated as internet-facing based on the most recent status recorded for it.
Instead of matching known web shell names, the query builds a baseline from the previous 30 days of process activity on each device and alerts when a pair appears in the latest window that has never been seen on that device before, so it can catch web shell activity it has never seen before. Because the baseline is held per device, a pair that is normal on one server does not hide the same pair appearing on another.
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.
Instead of matching known web shell names, the query builds a baseline from the previous 30 days of process activity on each device and alerts when a pair appears in the latest window that has never been seen on that device before, so it can catch web shell activity it has never seen before. Because the baseline is held per device, a pair that is normal on one server does not hide the same pair appearing on another.
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.
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.
Builds a 28-day hourly baseline of mail and file access operations (MailItemsAccessed, FileAccessed, FileDownloaded and SearchQueryPerformed) for each application identity and action type in CloudAppEvents, counting hours with no activity as zero, then alerts on each complete hour in the latest window where the identity’s operation count exceeds its average by more than three standard deviations and reaches a minimum volume.
Application identities legitimately read data at high volume, so a per-identity statistical baseline separates abuse of granted permissions from normal machine traffic where fixed thresholds fail. Identities with no activity in the baseline period are excluded, and a sustained change in behaviour, such as a large synchronisation or recovery job, will produce one result for each hour it remains elevated.
The rule runs every 24 hours, as this is the only Defender custom detection frequency with a 30-day lookback, and tests the 25 complete hours ending two hours before each run, allowing for audit log ingestion delays while overlapping the previous run so that no hour is missed.
Where the display name matches the AccountId, Defender for Cloud Apps could not name the identity, which is common for Microsoft first-party services, so analysts should confirm the application before drawing conclusions.
Application identities legitimately read data at high volume, so a per-identity statistical baseline separates abuse of granted permissions from normal machine traffic where fixed thresholds fail. Identities with no activity in the baseline period are excluded, and a sustained change in behaviour, such as a large synchronisation or recovery job, will produce one result for each hour it remains elevated.
The rule runs every 24 hours, as this is the only Defender custom detection frequency with a 30-day lookback, and tests the 25 complete hours ending two hours before each run, allowing for audit log ingestion delays while overlapping the previous run so that no hour is missed.
Where the display name matches the AccountId, Defender for Cloud Apps could not name the identity, which is common for Microsoft first-party services, so analysts should confirm the application before drawing conclusions.
This detection flags a parent and child process pair on internet-facing Windows servers, where the parent is a web server process and the child is the process it launched. The web server processes covered are w3wp, httpd, nginx and Tomcat, including versioned Tomcat service executables such as tomcat9.exe and Tomcat running under java.exe, which is identified by the Catalina bootstrap class in its command line. A server is treated as internet-facing based on the most recent status recorded for it.
Instead of matching known web shell names, the query builds a baseline from the previous 30 days of process activity on each device and alerts when a pair appears in the latest window that has never been seen on that device before, so it can catch web shell activity it has never seen before. Because the baseline is held per device, a pair that is normal on one server does not hide the same pair appearing on another.
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.
Instead of matching known web shell names, the query builds a baseline from the previous 30 days of process activity on each device and alerts when a pair appears in the latest window that has never been seen on that device before, so it can catch web shell activity it has never seen before. Because the baseline is held per device, a pair that is normal on one server does not hide the same pair appearing on another.
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.
This detection flags a parent and child process pair on internet-facing Windows servers, where the parent is a web server process and the child is the process it launched. The web server processes covered are w3wp, httpd, nginx and Tomcat, including versioned Tomcat service executables such as tomcat9.exe and Tomcat running under java.exe, which is identified by the Catalina bootstrap class in its command line. A server is treated as internet-facing based on the most recent status recorded for it.
Instead of matching known web shell names, the query builds a baseline from the previous 30 days of process activity on each device and alerts when a pair appears in the latest window that has never been seen on that device before, so it can catch web shell activity it has never seen before. Because the baseline is held per device, a pair that is normal on one server does not hide the same pair appearing on another.
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.
Instead of matching known web shell names, the query builds a baseline from the previous 30 days of process activity on each device and alerts when a pair appears in the latest window that has never been seen on that device before, so it can catch web shell activity it has never seen before. Because the baseline is held per device, a pair that is normal on one server does not hide the same pair appearing on another.
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.
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.
This rule detects potentially malicious activity leveraging the Windows Certutil utility for downloading, decoding, and executing files or payloads. It monitors process command line arguments to identify common download flags, hex/base64 decoding operations, evasion techniques, and interaction with high-risk file types or directories. The rule calculates a severity score based on the combination of these behaviors, such as downloading and decoding a file, or executing content from a temporary directory.
This rule detects the use of the Windows Boot Configuration Data Editor (bcdedit.exe) to modify system recovery settings. Specifically, it looks for attempts to disable recovery features or instruct the boot manager to ignore failures. Such modifications are common in ransomware and destructive attacks to prevent users from using Windows recovery tools to restore the system or access backups.
This rule detects the use of native Windows utilities 'vssadmin.exe' and 'wmic.exe' to delete Volume Shadow Copies. This activity is a common tactic used by ransomware and other malicious actors to prevent system recovery by destroying backups, and is classified as Inhibit System Recovery.
This rule detects the use of the 'bcdedit.exe' utility to modify Windows Boot Configuration Data (BCD) settings to disable system recovery features, such as boot recovery or automatic failure handling. Such actions are commonly performed by ransomware or other destructive malware to prevent system restoration after encryption or data damage.
Page 1 of 6