Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,088 detections
Filters
Last updated
All Time
Detection languages
619
191
113
86
47
Contributors
302
211
112
88
54
Categories
481
416
353
192
164
Platforms
726
348
216
136
57
Products / Services
518
292
197
124
88
MITRE Techniques
18,123
15,639
12,581
8,394
6,215
1,088
CVEs
5
5
5
5
4
IDS Classtypes
3
2
1
1
IDS Protocols
3
Detects a sequence of events characteristic of exploitation against RouterOS (CVE-2026-67276/CVE-2026-86060), involving a failed SSH login attempt with the username '-2', followed by the creation of a new user account within the same SSH session, and a successful login with that newly created account.
Detects a sequence of events characteristic of exploitation against RouterOS (CVE-2026-67276/CVE-2026-86060), involving a failed SSH login attempt with the username '-2', followed by the creation of a new user account within the same SSH session, and a successful login with that newly created account.
Detects high-privilege user accounts (e.g., executives, administrators) undergoing a credential or MFA reset, followed by an atypical sign-in event within a two-hour window. This pattern is indicative of potential account takeover or identity-compromise scenarios, often associated with help-desk vishing attacks where an attacker induces a user or administrator to reset credentials or MFA methods.
Detects a two-stage activity: first, the potential unauthorized reading or access of LLM provider API keys from files, environment variables, or command-line arguments; and second, the subsequent use of those same credentials to authenticate to LLM provider APIs (OpenAI, Anthropic, Azure, Bedrock) from a different, unrecognized source IP address, indicating potential credential theft and session hijacking.
Detects anomalous sign-in patterns indicative of real-time MFA relay attacks, where a user principal authenticates successfully from multiple distinct IP addresses and geographical locations within a short time window (15 minutes), suggesting the active interception of credentials and MFA challenges by a Phishing-as-a-Service platform.
Detects the creation or modification of Google Cloud Config Connector (KCC) IAM resources (IAMPolicyMember, IAMPartialPolicy, IAMPolicy) that assign high-privilege roles like 'roles/owner' or 'roles/resourcemanager.organizationAdmin'. This monitors for potential privilege escalation where a low-privilege actor leverages the KCC controller's high-privilege service account to perform unauthorized IAM binding changes on Google Cloud resources.
Joins password reset events to subsequent legacy-protocol (IMAP/POP/SMTP/ActiveSync) or non-interactive sign-ins for the same user, catching attackers who pivot to less-monitored protocols immediately after a vished self-service reset.
Detects the presence or execution of artifacts associated with the TrustSink proof-of-concept (deploy.py, cleanup_eam.py, deploy_state.json), which is used to register or remove rogue Entra authentication providers.
Single-source Sigma proxy for the authentication-persistence stage of the multi-stage device-code-phishing-to-Graph-collection chain (see the companion KQL correlation rule "Passkey Persistence: Device-Code Phishing to MFA Takeover and Graph Collection" for the full, threshold-gated, cross-table detection). Sigma has no join, temporal-windowing, or aggregation support, so this rule fires on the authentication-persistence event alone and does NOT enforce the device-code sign-in precursor or the subsequent Graph-activity burst - both required by the full correlation. Scoped to the two highest-signal operations only (new security-info registration, and any admin-initiated registration on another user's account) to cut noise from routine self-service profile edits.
Single-source Sigma proxy for the authentication-persistence stage of the multi-stage device-code-phishing-to-Graph-collection chain (see the companion KQL correlation rule "Passkey Persistence: Device-Code Phishing to MFA Takeover and Graph Collection" for the full, threshold-gated, cross-table detection). Sigma has no join, temporal-windowing, or aggregation support, so this rule fires on the authentication-persistence event alone and does NOT enforce the device-code sign-in precursor or the subsequent Graph-activity burst - both required by the full correlation. Scoped to the two highest-signal operations only (new security-info registration, and any admin-initiated registration on another user's account) to cut noise from routine self-service profile edits.
Detects instances where a user account registers a new Multi-Factor Authentication (MFA) method (such as TOTP or Authenticator app) shortly (within 30 minutes) after a high-risk or potentially anomalous sign-in event. This pattern is commonly associated with adversary-in-the-middle (AiTM) phishing attacks where an attacker captures an authenticated session and uses it to enroll a secondary, attacker-controlled MFA device for persistent account access.
Detects a single identity listing access keys for a high volume (20+) of Azure Storage Accounts within a 15-minute window. This behavior is indicative of credential harvesting, reconnaissance, or automated exfiltration attempts targeting storage resources.
Detects non-interactive Microsoft Entra ID service principal or managed identity sign-in events originating from an IP address, ASN, or country that has not been historically associated with that specific service principal. This behavior may indicate the use of compromised service principal credentials or stolen access tokens from adversary-controlled infrastructure.
Detects chained AWS STS AssumeRole/AssumeRoleWithSAML/AssumeRoleWithWebIdentity events where a principal assumes a role in a different account and then quickly performs another role assumption from that new context. This pattern, often referred to as 'role chaining' or 'role laundering', is frequently used to obfuscate identity tracking and facilitate lateral movement across AWS account boundaries.
Detects the use of iam:PassRole to attach a potentially highly privileged IAM role (e.g., Administrator, PowerUser, FullAccess) to newly created or modified compute or serverless resources (EC2 instances, Lambda functions, Launch Templates, or Auto Scaling Groups). This behavior is indicative of an attacker attempting to escalate privileges by granting a managed resource excessive permissions that the attacker can subsequently abuse.
Detects the creation of programmatic API credentials or service principal keys by highly privileged cloud identities across AWS, Azure, and GCP. Specifically monitors AWS Root, Azure AD Global/Company Administrators, and GCP Organization Owners, whose roles generally do not require long-term API access.
Detects successful cloud console login events across AWS, Azure, and GCP where multi-factor authentication (MFA) was not utilized, combined with impossible travel indicators (login from different countries within an 8-hour window for the same principal).
Detects instances where an Entra ID (Azure AD) application is registered and subsequently granted consent by the same user within 30 minutes, specifically when the activity occurs outside of typical business hours (7 AM - 7 PM) or from disparate IP addresses. This behavior pattern is indicative of potential malicious OAuth application registration and subsequent token-granting by an attacker to maintain persistent access to an environment.
Detects anomalous cross-account AssumeRole activities, including chained role assumptions, which are often used by cloud-native intrusion sets to launder access, evade single-account logging detection, and move laterally across AWS environments. The rule identifies AssumeRole events targeting non-allowlisted accounts or sequences where credentials are immediately used to perform further cross-account assumptions.
Detects the creation or modification of credentials (access keys or login profiles) for the AWS root account or identities explicitly named to imply high-privilege administrative access. This is a high-fidelity indicator of persistence or unauthorized privilege escalation within an AWS environment.
This rule detects the launch of an AWS EC2 instance that is configured with an IAM instance profile containing administrative keywords (e.g., AdministratorAccess, FullAccess) or a wildcard (*). Attackers can abuse this configuration after gaining initial access to the console or API to attach an over-privileged profile to a new instance, then pivot to the instance metadata service (IMDS) to extract these administrative credentials for persistent, broadly-scoped access.
Page 7 of 52