EXPLORE DETECTIONS
Spike in Special Privilege Use Events
A machine learning job has detected an unusual increase in special privilege usage events, such as privileged operations and service calls, for a user, suggesting potential unauthorized privileged access. A sudden spike in these events may indicate an attempt to escalate privileges, execute unauthorized tasks, or maintain persistence within a system.
Spike in Successful Logon Events from a Source IP
A machine learning job found an unusually large spike in successful authentication events from a particular source IP address. This can be due to password spraying, user enumeration or brute force activity.
Spike in User Account Management Events
A machine learning job has identified a spike in user account management events for a user, indicating potential privileged access activity. This indicates an unusual increase in actions related to managing user accounts (such as creating, modifying, or deleting accounts), which could be a sign of an attempt to escalate privileges or unauthorized activity involving account management.
Spike in User Lifecycle Management Change Events
A machine learning job has identified an unusual spike in Okta user lifecycle management change events, indicating potential privileged access activity. Threat actors may manipulate user accounts to gain higher access rights or persist within the environment.
Splunk Enterprise PostgreSQL Backup-to-Restore Potential RCE Sequence
Detects a POST to the Splunk Enterprise PostgreSQL backup endpoint followed by a POST to the restore endpoint from the same client to the same host within a 15-minute window. This sequence is unusual and can align with the public CVE-2026-20253 pre-authentication RCE chain, where an attacker stages a database dump via the backup path and executes attacker-controlled SQL via the restore path.
Splunk Enterprise PostgreSQL Recovery Endpoint Injection Artifacts
Detects CVE-2026-20253 exploit artifacts against the Splunk Enterprise PostgreSQL sidecar recovery endpoints via complementary signals. Where endpoint or Network Packet Capture request-body logging is available, the rule matches PostgreSQL connection-string injection keywords, suspicious `backupFile` destinations, and known filesystem artifacts used to pivot from backup/restore primitives to file write or RCE. It also detects vulnerable recovery endpoint probing and empty-password Basic auth credentials observed in public exploit tooling.
Splunk External Alerts
Generates a detection alert for each Splunk alert written to the configured indices. Enabling this rule allows you to immediately begin investigating Splunk alerts in the app.
SSFileCopyReceiver Writing to Common Persistence Locations
Identifies the macOS Screen Sharing file copy helper SSFileCopyReceiver creating or modifying files in common persistence locations, including system-wide and per-user LaunchDaemons/LaunchAgents, shell profiles, SSH authorized_keys, cron tabs, and hidden paths under root's home directory. SSFileCopyReceiver performs file writes with root authority on behalf of a remote viewer.Pre-authentication exploitation of the Screen Sharing service (CVE-2026-65400) abuses this write primitive to establish persistence; observed in-the-wild activity dropped LaunchDaemons and modified shell startup files to run a cryptocurrency miner as root.
SSFileCopySender Executed as Root
Identifies execution of the macOS Screen Sharing file-copy helper SSFileCopySender with root UID/GID attributes (0 80). Under the native Apple authentication path this helper runs in the connecting user's context; execution as root is anomalous and consistent with pre-authentication exploitation of the Screen Sharing service (CVE-2026-65400), where a flawed SRP validation path lets an unauthenticated attacker reach privileged file operations. Note that the 0/80 UID/GID pair reflects only initial exploitation attempts and can be evaded once an attacker enumerates another local account. It is advisable to treat this as a tripwire and pair it with the SSFileCopyReceiver Writing to Common Persistence Locations rule coverage.
SSH Authorized Key File Activity Detected via Defend for Containers
This rule detects the creation or modification of an authorized_keys file inside a container. The Secure Shell (SSH) authorized_keys file specifies which users are allowed to log into a server using public key authentication. Adversaries may modify it to maintain persistence on a victim host by adding their own public key(s). Unexpected and unauthorized SSH usage inside a container can be an indicator of compromise and should be investigated.
SSH Authorized Keys File Activity
The Secure Shell (SSH) authorized_keys file specifies which users are allowed to log into a server using public key authentication. Adversaries may modify it to maintain persistence on a victim host by adding their own public key(s).
SSH Authorized Keys File Deletion
This rule detects the deletion of the authorized_keys or authorized_keys2 files on Linux systems. These files are used to store public keys for SSH authentication. Unauthorized deletion of these files can be an indicator of an attacker removing access to the system, and may be a precursor to further malicious activity.
SSH Key Generated via ssh-keygen
This rule identifies the creation of SSH keys using the ssh-keygen tool, which is the standard utility for generating SSH keys. Users often create SSH keys for authentication with remote services. However, threat actors can exploit this tool to move laterally across a network or maintain persistence by generating unauthorized SSH keys, granting them SSH access to systems.
SSL Certificate Deletion
This rule detects the deletion of SSL certificates on a Linux system. Adversaries may delete SSL certificates to subvert trust controls and negatively impact the system.
Startup Folder Persistence via Unsigned Process
Identifies files written or modified in the startup folder by unsigned processes. Adversaries may abuse this technique to maintain persistence in an environment.
Startup or Run Key Registry Modification
Identifies run key or startup key registry modifications. In order to survive reboots and other system interrupts, attackers will modify run keys within the registry or leverage startup folder items as a form of persistence.
Startup Persistence by a Suspicious Process
Identifies files written to or modified in the startup folder by commonly abused processes. Adversaries may use this technique to maintain persistence.
Startup/Logon Script added to Group Policy Object
Detects the modification of Group Policy Objects (GPO) to add a startup/logon script to users or computer objects.
Statistical Model Detected C2 Beaconing Activity
A statistical model has identified command-and-control (C2) beaconing activity. Beaconing can help attackers maintain stealthy communication with their C2 servers, receive instructions and payloads, exfiltrate data and maintain persistence in a network.
Statistical Model Detected C2 Beaconing Activity with High Confidence
A statistical model has identified command-and-control (C2) beaconing activity with high confidence. Beaconing can help attackers maintain stealthy communication with their C2 servers, receive instructions and payloads, exfiltrate data and maintain persistence in a network.
Stolen Credentials Used to Login to Okta Account After MFA Reset
Detects a sequence of suspicious activities on Windows hosts indicative of credential compromise, followed by efforts to undermine multi-factor authentication (MFA) and single sign-on (SSO) mechanisms for an Okta user account.
Sublime Plugin or Application Script Modification
Adversaries may create or modify the Sublime application plugins or scripts to execute a malicious payload each time the Sublime application is started.
Successful AMQP Multi-Queue Purge Burst
Identifies multiple successful AMQP queue purge operations issued by the same client to the same broker within a short period. The AMQP queue.purge method removes all messages from a queue that are not awaiting acknowledgment. Purging several distinct queues can indicate deliberate message destruction or disruption after broker credentials are compromised.
Successful Application SSO from Rare Unknown Client Device
Detects successful single sign-on (SSO) events to Okta applications from an unrecognized or "unknown" client device, as identified by the user-agent string. This activity may be indicative of exploitation of a vulnerability in Okta's Classic Engine, which could allow an attacker to bypass application-specific sign-on policies, such as device or network restrictions. The vulnerability potentially enables unauthorized access to applications using only valid, stolen credentials, without requiring additional authentication factors.