Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
31 detections
Filters
Last updated
All Time
Detection languages
12
12
7
Contributors
12
7
5
3
1
Categories
25
8
7
5
4
Platforms
20
8
3
1
Products / Services
11
7
4
4
3
MITRE Techniques
18,114
15,634
12,576
8,388
6,215
This rule detects an unusually high number of firewall rule changes (Event ID 4948) occurring on a single computer within a one-hour window. A sudden surge in firewall modifications can indicate malicious activity, such as an attacker attempting to establish persistence, bypass security controls, or facilitate lateral movement by opening new ports or disabling existing rules.
This rule detects an unusually high number of firewall rule changes (Event ID 4948) occurring on a single computer within a one-hour window. A sudden surge in firewall modifications can indicate malicious activity, such as an attacker attempting to establish persistence, bypass security controls, or facilitate lateral movement by opening new ports or disabling existing rules.
This rule detects an unusually high number of firewall rule changes (Event ID 4948) occurring on a single computer within a one-hour window. A sudden surge in firewall modifications can indicate malicious activity, such as an attacker attempting to establish persistence, bypass security controls, or facilitate lateral movement by opening new ports or disabling existing rules.
This rule detects configuration changes to Fortinet FortiGate firewall policies that occur outside of standard business hours (before 8 AM or after 5 PM NZDT). It specifically looks for actions like 'Move', 'Add', 'Enable', 'Delete', or 'Edit' on firewall policies. This can indicate unauthorized access or malicious activity, as legitimate changes are typically performed during business hours.
This rule identifies and aggregates blocked requests from Imperva WAF logs, grouping them by source IP address and then by the owning organization (ASN). It helps to detect and analyze potential attack campaigns or coordinated malicious activity originating from specific organizations or IP ranges. The rule focuses on security, session, and visitor blocks, providing details on attack names, query strings, referrers, and URLs.
Detects remote RPC calls to the ITaskSchedulerService interface, specifically focusing on operations that create or execute scheduled tasks. This behavior is commonly associated with lateral movement and persistence techniques. The rule leverages an RPC Firewall to monitor these specific RPC calls.
Detects when a new rule has been added to the Windows Firewall exception list, specifically looking for uncommon or potentially malicious additions by filtering out common system paths and applications. This rule aims to identify defense evasion attempts where adversaries modify firewall rules to allow their command and control traffic or other malicious network activity.
This rule detects successful network connections from external (internet) IP addresses to common Industrial Control System (ICS) ports, such as Modbus (502) and EtherNet/IP (44818). This activity could indicate unauthorized access attempts, reconnaissance, or exploitation of internet-exposed ICS assets. The rule specifically filters for allowed/accepted/permitted connections and excludes connections from RFC 1918 private IP addresses and a configurable list of authorized external IPs.
The analytic identifies allowed network traffic to The Onion Router (TOR), an anonymity network often exploited for malicious activities. It leverages data from Next Generation Firewalls to detect traffic where the application is TOR and the action is allowed. This activity is significant as TOR can be used to bypass conventional monitoring, facilitating hacking, data breaches, and illicit content dissemination. If confirmed malicious, this could lead to unauthorized access, data exfiltration, and severe compliance violations, compromising the integrity and security of the network.
The following analytic detects a blocked connection event by identifying a "Block" value in the action field. It leverages logs from Cisco Secure Firewall Threat Defense devices. This activity is significant as it can identify attempts from users or applications initiating network connection to explicitly or implicitly blocked range or zones. If confirmed malicious, attackers could be attempting to perform a forbidden action on the network such as data exfiltration, lateral movement, or network disruption.
KQL Query from file: Detecting Palo Alto Firewall Exploits
'Identifies a match for SQL Injection attack in the Application gateway WAF logs. The Threshold value in the query can be changed as per your infrastructure's requirement.
References: https://owasp.org/Top10/A03_2021-Injection/'
References: https://owasp.org/Top10/A03_2021-Injection/'
This query will show rare firewall rule changes using netsh utility by comparing rule names and program names from the previous day
with those from the historical chosen time frame.
- This technique was seen in relation to Solarigate attack but the results can indicate potential malicious activity used in different attacks.
- The process name in each data source is commented out as an adversary could rename it. It is advisable to keep process name commented but
if the results show unrelated false positives, users may want to uncomment it.
- Note also that the queries use the KQL "has_all" operator, which hasn't yet been documented officially, but will be soon.
In short, "has_all" will only match when the referenced field has all strings in the list.
Refer to netsh syntax: https://docs.microsoft.com/windows-server/administration/windows-commands/netsh
Refer to our Microsoft Defender XDR blog for details on use during the Solorigate attack:
https://www.microsoft.com/security/blog/2021/01/20/deep-dive-into-the-solorigate-second-stage-activation-from-sunburst-to-teardrop-and-raindrop/
with those from the historical chosen time frame.
- This technique was seen in relation to Solarigate attack but the results can indicate potential malicious activity used in different attacks.
- The process name in each data source is commented out as an adversary could rename it. It is advisable to keep process name commented but
if the results show unrelated false positives, users may want to uncomment it.
- Note also that the queries use the KQL "has_all" operator, which hasn't yet been documented officially, but will be soon.
In short, "has_all" will only match when the referenced field has all strings in the list.
Refer to netsh syntax: https://docs.microsoft.com/windows-server/administration/windows-commands/netsh
Refer to our Microsoft Defender XDR blog for details on use during the Solorigate attack:
https://www.microsoft.com/security/blog/2021/01/20/deep-dive-into-the-solorigate-second-stage-activation-from-sunburst-to-teardrop-and-raindrop/
'Identifies a match for XSS attack in the Application gateway WAF logs. The Threshold value in the query can be changed as per your infrastructure's requirement.
References: https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)'
References: https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)'
Get all filtering events done by the Windows filtering platform.
This includes any blocks done by Windows Firewall rules, but also blocks triggered by some 3rd party firewalls.
When no Firewall rules are configured, the default behavior is to block all incoming network connections.
This includes any blocks done by Windows Firewall rules, but also blocks triggered by some 3rd party firewalls.
When no Firewall rules are configured, the default behavior is to block all incoming network connections.
Determines DeviceId from internal IP address and outputs all alerts in events table associated to the DeviceId.
Example use case is Firewall determines Internal IP with suspicious network activity. Query WDATP based on date/time and Internal IP and see associated alerts for the endpoint.
Example use case is Firewall determines Internal IP with suspicious network activity. Query WDATP based on date/time and Internal IP and see associated alerts for the endpoint.
This rule detects remote procedure calls (RPC) targeting the MS-SRVS interface (UUID: 4b324fc8-1670-01d3-1278-5a47bf6ee188) which is associated with the Server Service. Abuse of this service can be used for lateral movement within a network, potentially for creating remote shares or other administrative functions. The detection relies on logs from an RPC Firewall.
This rule detects remote RPC calls made to query information about scheduled tasks. Specifically, it monitors for RPC Firewall events (EventID 3) with a specific InterfaceUuid (86d35949-83c9-4044-b424-db363231fd0c) which corresponds to the ITaskSchedulerService. The rule filters out common operational numbers (OpNum 1, 3, 4, 10, 11, 12, 13, 14, 15) to reduce false positives, focusing on less common or potentially malicious reconnaissance activities related to scheduled tasks.
This analytic highlights high-impact intrusion events detected by Cisco Secure Firewall. It leverages Cisco Secure Firewall Threat Defense logs, specifically the IntrusionEvent event type, and focuses on events with an `Impact` score of 1 or 2. If confirmed malicious, these events may indicate a potentially compromised host.
This analytic detects suspicious modifications to Windows firewall rules via the registry. Specifically, it looks for changes that allow inbound traffic on any port with a public profile. This activity is significant as it may indicate an adversary attempting to grant remote access to a machine by modifying firewall rules, potentially leading to unauthorized remote access, further exploitation, data exfiltration, or lateral movement within the network.
This detection identifies instances where a Windows Firewall rule has been deleted, potentially exposing the system to security risks. Unauthorized removal of firewall rules can indicate an attacker attempting to bypass security controls or malware disabling protections for persistence and command-and-control communication. The event logs details such as the deleted rule name, protocol, port, and the user responsible for the action. Security teams should monitor for unexpected deletions, correlate with related events, and investigate anomalies to prevent unauthorized access and maintain network security posture.
Page 1 of 2