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,931
7,261
6,535
3,864
3,642
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
The analytic identifies threats detected by Okta ThreatInsight, such as password spraying, login failures, and high counts of unknown user login attempts. It leverages Okta Identity Management logs, specifically focusing on `security.threat.detected` events. This activity is significant for a SOC as it highlights potential unauthorized access attempts and credential-based attacks. If confirmed malicious, these activities could lead to unauthorized access, data breaches, and further exploitation of compromised accounts, posing a significant risk to the organization's security posture.
The following analytic identifies an attempt to disable multi-factor authentication (MFA) for an Okta user. It leverages OktaIM2 logs to detect when the 'user.mfa.factor.deactivate' command is executed. This activity is significant because disabling MFA can allow an adversary to maintain persistence within the environment using a compromised valid account. If confirmed malicious, this action could enable attackers to bypass additional security layers, potentially leading to unauthorized access to sensitive information and prolonged undetected presence in the network.
The following analytic identifies instances where the same Okta user logs in from different cities within a 24-hour period. This detection leverages Okta Identity Management logs, analyzing login events and their geographic locations. Such behavior is significant as it may indicate a compromised account, with an attacker attempting unauthorized access from multiple locations. If confirmed malicious, this activity could lead to account takeovers and data breaches, allowing attackers to access sensitive information and potentially escalate their privileges within the environment.
The following analytic detects when a repository is archived in GitHub Enterprise. The detection monitors GitHub Enterprise audit logs for repository archival events by tracking actor details, repository information, and associated metadata. For a SOC, identifying repository archival is important as it could indicate attempts to make critical code inaccessible or preparation for repository deletion. While archiving is a legitimate feature, unauthorized archival of active repositories could signal account compromise, insider threats, or attempts to disrupt development operations. The impact of unauthorized repository archival includes loss of active development access, disruption to workflows and CI/CD pipelines, and potential business delays if critical repositories are affected. Additionally, archived repositories may be targeted for subsequent deletion, potentially resulting in permanent loss of intellectual property if proper backups are not maintained.
The following analytic detects when a user disables audit log event streaming in GitHub Enterprise. The detection monitors GitHub Enterprise audit logs for configuration changes that disable the audit log streaming functionality, which is used to send audit events to security monitoring platforms. This behavior could indicate an attacker attempting to prevent their malicious activities from being logged and detected by disabling the audit trail. For a SOC, identifying the disabling of audit logging is critical as it may be a precursor to other attacks where adversaries want to operate undetected. The impact could be severe as organizations lose visibility into user actions, configuration changes, and security events within their GitHub Enterprise environment, potentially allowing attackers to perform malicious activities without detection. This creates a significant blind spot in security monitoring and incident response capabilities.
The following analytic detects when a user modifies or disables audit log event streaming in GitHub Enterprise. The detection monitors GitHub Enterprise audit logs for configuration changes that affect the audit log streaming functionality, which is used to send audit events to security monitoring platforms. This behavior could indicate an attacker attempting to prevent their malicious activities from being logged and detected by tampering with the audit trail. For a SOC, identifying modifications to audit logging is critical as it may be a precursor to other attacks where adversaries want to operate undetected. The impact could be severe as organizations lose visibility into user actions, configuration changes, and security events within their GitHub Enterprise environment, potentially allowing attackers to perform malicious activities without detection. This creates a significant blind spot in security monitoring and incident response capabilities.
The following analytic identifies when an associate reports a login attempt as suspicious via an email from Okta. It leverages Okta Identity Management logs, specifically the `user.account.report_suspicious_activity_by_enduser` event type. This activity is significant as it indicates potential unauthorized access attempts, warranting immediate investigation to prevent possible security breaches. If confirmed malicious, the attacker could gain unauthorized access to sensitive systems and data, leading to data theft, privilege escalation, or further compromise of the environment.
The analytic detects when branch rules are deleted in GitHub Enterprise. The detection monitors GitHub Enterprise audit logs for branch rule deletion events by tracking actor details, repository information, and associated metadata. For a SOC, identifying deleted branch rules is critical as it could indicate attempts to bypass code review requirements and security controls. Branch deletion rules are essential security controls that enforce code review, prevent force pushes, and maintain code quality. Disabling these protections could allow malicious actors to directly push unauthorized code changes or backdoors to protected branches. The impact of disabled branch protection includes potential code tampering, bypass of security reviews, introduction of vulnerabilities or malicious code, and compromise of software supply chain integrity. This activity could be part of a larger attack chain where an adversary first disables security controls before attempting to inject malicious code.
The following analytic detects when classic branch protection rules are disabled in GitHub Enterprise. The detection monitors GitHub Enterprise audit logs for branch protection removal events by tracking actor details, repository information, and associated metadata. For a SOC, identifying disabled branch protection is critical as it could indicate attempts to bypass code review requirements and security controls. Branch protection rules are essential security controls that enforce code review, prevent force pushes, and maintain code quality. Disabling these protections could allow malicious actors to directly push unauthorized code changes or backdoors to protected branches. The impact of disabled branch protection includes potential code tampering, bypass of security reviews, introduction of vulnerabilities or malicious code, and compromise of software supply chain integrity. This activity could be part of a larger attack chain where an adversary first disables security controls before attempting to inject malicious code.
The analytic detects when a user disables Dependabot security features within a GitHub repository. Dependabot helps automatically identify and fix security vulnerabilities in dependencies. The detection monitors GitHub Enterprise logs for configuration changes that disable Dependabot functionality. This behavior could indicate an attacker attempting to prevent the automatic detection of vulnerable dependencies, which would allow them to exploit known vulnerabilities that would otherwise be patched. For a SOC, identifying the disabling of security features like Dependabot is critical as it may be a precursor to supply chain attacks where attackers exploit vulnerable dependencies. The impact could be severe if vulnerabilities remain unpatched, potentially leading to code execution, data theft, or other compromises through the software supply chain.
The following analytic identifies Gsuite emails with suspicious subjects and attachments commonly used in spear phishing attacks. It leverages Gsuite email logs, focusing on specific keywords in the subject line and known malicious file types in attachments. This activity is significant for a SOC as spear phishing is a prevalent method for initial compromise, often leading to further malicious actions. If confirmed malicious, this activity could result in unauthorized access, data exfiltration, or further malware deployment, posing a significant risk to the organization's security.
The following analytic identifies successful single-factor authentication events against the Okta Dashboard for accounts without Multi-Factor Authentication (MFA) enabled. It detects this activity by analyzing Okta logs for successful authentication events where "Okta Verify" is not used. This behavior is significant as it may indicate a misconfiguration, policy violation, or potential account takeover. If confirmed malicious, an attacker could gain unauthorized access to the account, potentially leading to data breaches or further exploitation within the environment.
The following analytic detects when a user pauses audit log event streaming in GitHub Enterprise. The detection monitors GitHub Enterprise audit logs for configuration changes that temporarily suspend the audit log streaming functionality, which is used to send audit events to security monitoring platforms. This behavior could indicate an attacker attempting to prevent their malicious activities from being logged and detected by temporarily disabling the audit trail. For a SOC, identifying the pausing of audit logging is critical as it may be a precursor to other attacks where adversaries want to operate undetected during the pause window. The impact could be severe as organizations temporarily lose visibility into user actions, configuration changes, and security events within their GitHub Enterprise environment, potentially allowing attackers to perform malicious activities without detection during the pause period. This creates a temporary blind spot in security monitoring and incident response capabilities.
The analytic identifies suspicious file-sharing activity on Google Drive, where internal users share documents with more than 50 external recipients. It leverages GSuite Drive logs, focusing on changes in user access and filtering for emails outside the organization's domain. This activity is significant as it may indicate compromised accounts or intentional data exfiltration. If confirmed malicious, this behavior could lead to unauthorized access to sensitive information, data leaks, and potential compliance violations.
The following analytic identifies when an IP allow list is disabled in GitHub Enterprise. The detection monitors GitHub Enterprise audit logs for actions related to disabling IP allow lists at the organization or enterprise level. This behavior is concerning because IP allow lists are a critical security control that restricts access to GitHub Enterprise resources to only trusted IP addresses. When disabled, it could indicate an attacker attempting to bypass access controls to gain unauthorized access from untrusted networks. The impact includes potential exposure of sensitive code repositories and GitHub Enterprise resources to access from any IP address. SOC teams should investigate such events, especially if they were not pre-approved changes, as they may indicate compromise of admin credentials or malicious insider activity.
This rule detects when anonymous links are used to access files from OneDrive. While this isn't always a sign of malicious activity, some organizations do not support the use of anonymous links because of the risk of data leakage. The rule specifically looks for 'USER_RESOURCE_ACCESS' events with 'AnonymousLinkUsed' as the product event type, originating from 'Office 365' and 'Microsoft', where the user ID is 'anonymous'.
Detects file downloads using O365 or Graph Activity logs, not including anonymous file links
Anonymous links can be used to export files from OneDrive. While this isn't always a sign of malicious activity, some organizations do not support the creation of anonymous links because of the risk of data leakage. This rule detects the creation or modification of anonymous links in OneDrive.
Detects when an Okta user's password is reset and MFA factor(s) are deactivated or reset within a 30-minute time window. This activity may indicate that the user account has been compromised, as an attacker might reset the password and then disable MFA to maintain access.
Detects when a user grants access to a GitHub Personal Access Token (PAT) and subsequently clones a high number of non-public GitHub repositories. This behavior can indicate an adversary attempting to steal the contents of multiple GitHub repositories using an automated script or offensive tool after gaining access to a PAT.
Detects when third-party application access restrictions are disabled for a GitHub organization. This action can increase the attack surface by allowing unauthorized or malicious OAuth applications to access organization resources.
Page 134 of 142