Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
2,982 detections
Filters
Last updated
All Time
Detection languages
1,486
513
403
239
167
Contributors
986
658
304
198
109
Categories
916
822
673
590
452
Platforms
39,936
7,266
6,537
3,866
3,647
2,982
Products / Services
1,229
703
443
309
200
MITRE Techniques
1,053
824
459
384
348
CVEs
17
16
16
10
10
IDS Classtypes
24
7
7
4
3
IDS Protocols
49
1
This rule identifies events from Keeper BreachWatch indicating potential credential compromise. It specifically looks for logs categorized as 'breachwatch' and extracts details about the breach, including compromised domains and risk severity, along with the affected username and remote IP address.
Detects a high volume of 'git push --force' events specifically targeting tags from a single user or to a single repository within a short timeframe.
This is a strong indicator of a tag poisoning campaign, similar to the one used in the supply chain attack against the 'aquasecurity/trivy-action' repository where 75 tags were force-pushed to point to malicious code.
This is a strong indicator of a tag poisoning campaign, similar to the one used in the supply chain attack against the 'aquasecurity/trivy-action' repository where 75 tags were force-pushed to point to malicious code.
Detects a 'git push --force' event in GitHub audit logs. A force push overwrites the remote repository's history with the local history, which is a potentially destructive action.
This technique was notably used in the supply chain attack against the 'aquasecurity/trivy-action' repository, where attackers force-pushed malicious versions to existing version tags.
This technique was notably used in the supply chain attack against the 'aquasecurity/trivy-action' repository, where attackers force-pushed malicious versions to existing version tags.
Detects the presence of HTML tags within the URL query parameters of Claude chat application pre-fill URLs. Attackers can use this to embed invisible instructions (prompt injection) that the AI processes but the user does not see in the chat interface.
Detects access to the Zimbra mailbox export endpoint (/home/~/?fmt=tgz). This native Zimbra feature is actively abused by APT actors (such as in Operation GhostMail) to silently export emails without deploying custom collection tools.
Detects when a repository's branch protection, specifically the 'allow force pushes' enforcement level, is updated or disabled. This rule explicitly excludes events originating from automation scripts to reduce false positives.
This rule detects suspicious sign-in links that exhibit characteristics of OAuth redirect abuse. Specifically, it looks for URLs that contain "oauth2", "prompt=none", and "scope=invalid". This pattern suggests an attempt to use a trusted sign-in service to redirect users to a malicious page, potentially for phishing or malware delivery, by manipulating OAuth parameters.
Detects action of Repo branch protection being disabled by the means of a force push. This would mean no PR or review process is needed and an actor (Insider or attacker) could push arbitrary code.
Detects URL click events or browser launches where the URL targets Microsoft or Google OAuth endpoints and contains the combination of 'prompt=none' and 'scope=invalid'. This specific combination is used by attackers to force a silent error redirect to a malicious URI.
This rule is meant to help analysts quickly spot a high-confidence indicator related to Google AuraInspector Salesforce Aura Audit. It is written to be easy to understand and to keep false alarms low by focusing on a very specific match: an HTTP POST to a Salesforce /aura endpoint that includes specific Aura method strings. A match does not automatically prove an attacker is currently active, and it does not prove a file was executed, but it does mean the event is important because it lines up with a public threat intelligence source. When this triggers, start by identifying the host, user, and timeframe involved, then decide whether the activity is expected for that system. If it is unexpected, preserve the related logs and any files, and look for nearby events that could explain how the indicator appeared, such as a download, a new process, or a new connection. If the same indicator appears on multiple systems, treat it as a scoping signal and expand the investigation window. Use the reference link (https://cloud.google.com/blog/topics/threat- intelligence/auditing-salesforce-aura-data-exposure) to document where the indicator came from and to support incident notes and reporting.
Identifies consent grants to OAuth applications with Application IDs matching known malicious campaigns. The IOCs are sourced from Wiz Research on campaigns from 2019-2025 involving brand impersonation and consent phishing.
Detects when a user generates an unusually high number of prompts to Copilot within a short period (e.g., 50 prompts in an hour). This could indicate automated activity, data exfiltration attempts, or misuse of the Copilot service.
This rule detects attempts to grant consent to OAuth applications, which could indicate an illicit consent grant attack. It specifically looks for successful operations related to consenting to applications, adding app role assignments to service principals, adding delegated permission grants, or adding OAuth2PermissionGrants within audit logs. The rule extracts details such as the target application, the user who consented, their initiating IP address, and the permissions granted.
Detects action of git clone or git push in a repo where the source actor is not coming from a Corp IP Space. (Add your IP Blocks as needed to the filter)
This will show clearly the daily successful traffic for each day of the week, and then it will project the peak hours, medium and low hours of each day. And in the last column, it shows the Imperva rule that it hit, which also indicates if an attack was successful.
Detects action of Repo branch protection being disabled. This would mean no PR or review process is needed for that repo and an actor (Insider or attacker) could push arbitrary code. Bypassing usual Security controls.
Detects action of SSH ertificate Auth being disabled. This would mean password auth is allowed.
This could indicate an Authentication downgrade attack, disabling Security controls.
This could indicate an Authentication downgrade attack, disabling Security controls.
This rule detects HTTPS requests that should have been blocked but are not, for example:
Query Strings with malicious traits like 1=1, attempt to enter <script> in the URL,
URL containing ../ indicating Directory Traversal attempt, and so on.
Query Strings with malicious traits like 1=1, attempt to enter <script> in the URL,
URL containing ../ indicating Directory Traversal attempt, and so on.
This rule detects the use of the malicious GitHub Action 'ci-quality/code-quality-check@v1' associated with the SANDWORM_MODE campaign. This action is designed to harvest CI secrets and propagate the malware by being referenced in a GitHub workflow file. The rule searches for the specific string of the malicious GitHub action within file content or file/audit paths, specifically targeting GitHub workflow files (.yml or .yaml) in '.github/workflows/' directories.
Detects programmatic GitHub data exfiltration by identifying non-interactive repository exports, clones, artifact downloads, or gist staging performed using tokens, OAuth applications, or GitHub Apps. The detection focuses on bursty or multi-repository activity within a short time window, which can indicate automated source code collection, misuse of programmatic credentials, or post-compromise data extraction.
KQL to detect suspicious HTTP requests
Page 121 of 142