Update v8.6.10
editUpdate v8.6.10
editThis section lists all updates associated with version 8.6.10 of the Fleet integration Prebuilt Security Detection Rules.
| Rule | Description | Status | Version |
|---|---|---|---|
Identifies when a Microsoft 365 Mailbox is accessed by a ClientAppId that was observed for the fist time during the last 10 days. |
new |
1 |
|
Identifies multiple consecutive login attempts executed by one process targeting a local linux user account within a short time interval. Adversaries might brute force login attempts across different users with a default wordlist or a set of customly crafted passwords in an attempt to gain access to these accounts. |
new |
1 |
|
This rule leverages auditd to monitor for processes scanning different processes within the /proc directory using the openat syscall. This is a strong indication for the usage of the pspy utility. Attackers may leverage the pspy process monitoring utility to monitor system processes without requiring root permissions, in order to find potential privilege escalation vectors. |
new |
1 |
|
Identifies an attempt to exploit a local privilege escalation (CVE-2023-2640 and CVE-2023-32629) via a flaw in Ubuntu’s modifications to OverlayFS. These flaws allow the creation of specialized executables, which, upon execution, grant the ability to escalate privileges to root on the affected machine. |
new |
1 |
|
Potential Privilege Escalation through Writable Docker Socket |
This rule monitors for the usage of Docker runtime sockets to escalate privileges on Linux systems. Docker sockets by default are only be writable by the root user and docker group. Attackers that have permissions to write to these sockets may be able to create and run a container that allows them to escalate privileges and gain further access onto the host file system. |
new |
1 |
This rule is triggered when an IP address indicator from the Threat Intel Filebeat module or integrations has a match against a network event. |
update |
2 |
|
This rule is triggered when a hash indicator from the Threat Intel Filebeat module or integrations has a match against an event that contains file hashes, such as antivirus alerts, process creation, library load, and file operation events. |
update |
2 |
|
This rule is triggered when a Windows registry indicator from the Threat Intel Filebeat module or integrations has a match against an event that contains registry data. |
update |
2 |
|
This rule is triggered when a URL indicator from the Threat Intel Filebeat module or integrations has a match against an event that contains URL data, like DNS events, network logs, etc. |
update |
2 |
|
This rule detects when an unauthenticated user request is authorized within the cluster. Attackers may attempt to use anonymous accounts to gain initial access to the cluster or to avoid attribution of their activities within the cluster. This rule excludes the /healthz, /livez and /readyz endpoints which are commonly accessed anonymously. |
update |
5 |
|
Detects attempts to bypass Okta multi-factor authentication (MFA). An adversary may attempt to bypass the Okta MFA policies configured for an organization in order to obtain unauthorized access to an application. |
update |
104 |
|
Identifies when an Okta user account is locked out 3 times within a 3 hour window. An adversary may attempt a brute force or password spraying attack to obtain unauthorized access to user accounts. The default Okta authentication policy ensures that a user account is locked out after 10 failed authentication attempts. |
update |
104 |
|
Detects when an attacker abuses the Multi-Factor authentication mechanism by repeatedly issuing login requests until the user eventually accepts the Okta push notification. An adversary may attempt to bypass the Okta MFA policies configured for an organization to obtain unauthorized access. |
update |
104 |
|
Identifies a high number of failed Okta user authentication attempts from a single IP address, which could be indicative of a brute force or password spraying attack. An adversary may attempt a brute force or password spraying attack to obtain unauthorized access to user accounts. |
update |
104 |
|
A user has initiated a session impersonation granting them access to the environment with the permissions of the user they are impersonating. This would likely indicate Okta administrative access and should only ever occur if requested and expected. |
update |
104 |
|
Detects attempts to deactivate an Okta network zone. Okta network zones can be configured to limit or restrict access to a network based on IP addresses or geolocations. An adversary may attempt to modify, delete, or deactivate an Okta network zone in order to remove or weaken an organization’s security controls. |
update |
104 |
|
Detects attempts to delete an Okta network zone. Okta network zones can be configured to limit or restrict access to a network based on IP addresses or geolocations. An adversary may attempt to modify, delete, or deactivate an Okta network zone in order to remove or weaken an organization’s security controls. |
update |
104 |
|
Detects attempts to deactivate an Okta policy. An adversary may attempt to deactivate an Okta policy in order to weaken an organization’s security controls. For example, an adversary may attempt to deactivate an Okta multi-factor authentication (MFA) policy in order to weaken the authentication requirements for user accounts. |
update |
104 |
|
Detects attempts to deactivate a rule within an Okta policy. An adversary may attempt to deactivate a rule within an Okta policy in order to remove or weaken an organization’s security controls. |
update |
104 |
|
Detects attempts to delete an Okta policy. An adversary may attempt to delete an Okta policy in order to weaken an organization’s security controls. For example, an adversary may attempt to delete an Okta multi-factor authentication (MFA) policy in order to weaken the authentication requirements for user accounts. |
update |
104 |
|
Detects attempts to delete a rule within an Okta policy. An adversary may attempt to delete an Okta policy rule in order to weaken an organization’s security controls. |
update |
104 |
|
Detects attempts to modify an Okta network zone. Okta network zones can be configured to limit or restrict access to a network based on IP addresses or geolocations. An adversary may attempt to modify, delete, or deactivate an Okta network zone in order to remove or weaken an organization’s security controls. |
update |
104 |
|
Detects attempts to modify an Okta policy. An adversary may attempt to modify an Okta policy in order to weaken an organization’s security controls. For example, an adversary may attempt to modify an Okta multi-factor authentication (MFA) policy in order to weaken the authentication requirements for user accounts. |
update |
104 |
|
Detects attempts to modify a rule within an Okta policy. An adversary may attempt to modify an Okta policy rule in order to weaken an organization’s security controls. |
update |
104 |
|
Identifies a high number of Okta user password reset or account unlock attempts. An adversary may attempt to obtain unauthorized access to Okta user accounts using these methods and attempt to blend in with normal activity in their target’s environment and evade detection. |
update |
104 |
|
Identifies attempts to revoke an Okta API token. An adversary may attempt to revoke or delete an Okta API token to disrupt an organization’s business operations. |
update |
104 |
|
Detects attempts to deactivate an Okta application. An adversary may attempt to modify, deactivate, or delete an Okta application in order to weaken an organization’s security controls or disrupt their business operations. |
update |
104 |
|
Identifies file permission modifications in common writable directories by a non-root user. Adversaries often drop files or payloads into a writable directory and change permissions prior to execution. |
update |
104 |
|
This detection rule detects the creation of a shell through a suspicious parent child relationship. Any reverse shells spawned by the specified utilities that use a forked process to initialize the connection attempt will be captured through this rule. Attackers may spawn reverse shells to establish persistence onto a target system. |
update |
2 |
|
This detection rule identifies the execution of a Linux shell process from a Java JAR application post an incoming network connection. This behavior may indicate reverse shell activity via a Java application. |
update |
2 |
|
This detection rule detects the creation of a shell through a suspicious process chain. Any reverse shells spawned by the specified utilities that are initialized from a single process followed by a network connection attempt will be captured through this rule. Attackers may spawn reverse shells to establish persistence onto a target system. |
update |
2 |
|
This detection rule detects the creation of a shell through a chain consisting of the execution of a suspicious binary (located in a commonly abused location or executed manually) followed by a network event and ending with a shell being spawned. Stageless reverse tcp shells display this behaviour. Attackers may spawn reverse shells to establish persistence onto a target system. |
update |
2 |
|
This detection rule identifies suspicious network traffic patterns associated with TCP reverse shell activity. This activity consists of a parent-child relationship where a network event is followed by the creation of a shell process. An attacker may establish a Linux TCP reverse shell to gain remote access to a target system. |
update |
2 |
|
Files that are placed in the /etc/init.d/ directory in Unix can be used to start custom applications, services, scripts or commands during start-up. Init.d has been mostly replaced in favor of Systemd. However, the "systemd-sysv-generator" can convert init.d files to service unit files that run at boot. Adversaries may add or alter files located in the /etc/init.d/ directory to execute malicious code upon boot in order to gain persistence on the system. |
update |
3 |
|
Identifies the attempt to create a new backdoor user by setting the user’s UID to 0. Attackers may alter a user’s UID to 0 to establish persistence on a system. |
update |
2 |
|
Identifies attempts to create a new group. Attackers may create new groups to establish persistence on a system. |
update |
2 |
|
Identifies suspicious commands executed via a web server, which may suggest a vulnerability and remote shell access. Attackers may exploit a vulnerability in a web application to execute commands via a web server, or place a backdoor file that can be abused to gain code execution as a mechanism for persistence. |
update |
3 |
|
Identifies attempts to create new users. Attackers may add new users to establish persistence on a system. |
update |
2 |
|
Identifies attempts to add a user to a privileged group. Attackers may add users to a privileged group in order to establish persistence on a system. |
update |
2 |
|
Message of the day (MOTD) is the message that is presented to the user when a user connects to a Linux server via SSH or a serial connection. Linux systems contain several default MOTD files located in the "/etc/update-motd.d/" and "/usr/lib/update-notifier/" directories. These scripts run as the root user every time a user connects over SSH or a serial connection. Adversaries may create malicious MOTD files that grant them persistence onto the target every time a user connects to the system by executing a backdoor script or command. This rule detects the creation of potentially malicious files within the default MOTD file directories. |
update |
3 |
|
Message of the day (MOTD) is the message that is presented to the user when a user connects to a Linux server via SSH or a serial connection. Linux systems contain several default MOTD files located in the "/etc/update-motd.d/" and "/usr/lib/update-notifier/" directories. These scripts run as the root user every time a user connects over SSH or a serial connection. Adversaries may create malicious MOTD files that grant them persistence onto the target every time a user connects to the system by executing a backdoor script or command. This rule detects the execution of potentially malicious processes through the MOTD utility. |
update |
3 |
|
This rule monitors the creation/alteration of the rc.local file by a previously unknown process executable through the use of the new terms rule type. The /etc/rc.local file is used to start custom applications, services, scripts or commands during start-up. The rc.local file has mostly been replaced by Systemd. However, through the "systemd-rc-local-generator", rc.local files can be converted to services that run at boot. Adversaries may alter rc.local to execute malicious code at start-up, and gain persistence onto the system. |
update |
104 |
|
Detects the creation of a systemd timer within any of the default systemd timer directories. Systemd timers can be used by an attacker to gain persistence, by scheduling the execution of a command or script. Similarly to cron/at, systemd timers can be set up to execute on boot time, or on a specific point in time, which allows attackers to regain access in case the connection to the infected asset was lost. |
update |
3 |
|
Identifies the use of the Exchange PowerShell cmdlet, New-MailBoxExportRequest, to export the contents of a primary mailbox or archive to a .pst file. Adversaries may target user email to collect sensitive information. |
update |
4 |
|
PowerShell Suspicious Script with Audio Capture Capabilities |
Detects PowerShell scripts that can record audio, a common feature in popular post-exploitation tooling. |
update |
107 |
PowerShell Suspicious Script with Clipboard Retrieval Capabilities |
Detects PowerShell scripts that can get the contents of the clipboard, which attackers can abuse to retrieve sensitive information like credentials, messages, etc. |
update |
5 |
Detects the use of Win32 API Functions that can be used to capture user keystrokes in PowerShell scripts. Attackers use this technique to capture user input, looking for credentials and/or other valuable data. |
update |
108 |
|
First Time Seen Commonly Abused Remote Access Tool Execution |
Adversaries may install legitimate remote access tools (RAT) to compromised endpoints for further command-and-control (C2). Adversaries can rely on installed RATs for persistence, execution of native commands and more. This rule detects when a process is started whose name or code signature resembles commonly abused RATs. This is a New Terms rule type indicating the host has not seen this RAT process started before within the last 30 days. |
update |
3 |
This rule identifies when a User Account starts the Active Directory Replication Process for the first time. Attackers can use the DCSync technique to get credential information of individual accounts or the entire domain, thus compromising the entire domain. |
update |
5 |
|
This rule identifies when a User Account starts the Active Directory Replication Process. Attackers can use the DCSync technique to get credential information of individual accounts or the entire domain, thus compromising the entire domain. |
update |
108 |
|
Detects PowerShell scripts that contain the default exported functions used on Invoke-NinjaCopy. Attackers can use Invoke-NinjaCopy to read SYSTEM files that are normally locked, such as the NTDS.dit file or registry hives. |
update |
4 |
|
Detects PowerShell scripts that have the capability of requesting kerberos tickets, which is a common step in Kerberoasting toolkits to crack service accounts. |
update |
107 |
|
Identifies the execution of PowerShell script with keywords related to different Antimalware Scan Interface (AMSI) bypasses. An adversary may attempt first to disable AMSI before executing further malicious powershell scripts to evade detection. |
update |
6 |
|
Detects the use of Reflection.Assembly to load PEs and DLLs in memory in PowerShell scripts. Attackers use this method to load executables and DLLs without writing to the disk, bypassing security solutions. |
update |
108 |
|
Identifies the use of .NET functionality for decompression and base64 decoding combined in PowerShell scripts, which malware and security tools heavily use to deobfuscate payloads and load them directly in memory to bypass defenses. |
update |
108 |
|
Identifies the use of Cmdlets and methods related to encryption/decryption of files in PowerShell scripts, which malware and offensive security tools can abuse to encrypt data or decrypt payloads to bypass security solutions. |
update |
5 |
|
Identifies a process termination event quickly followed by the deletion of its executable file. Malware tools and other non-native files dropped or created on a system by an adversary may leave traces to indicate to what occurred. Removal of these files can occur during an intrusion, or as part of a post-intrusion process to minimize the adversary’s footprint. |
update |
105 |
|
Detects file name patterns generated by the use of Sysinternals SDelete utility to securely delete a file via multiple file overwrite and rename operations. |
update |
105 |
|
Identifies the execution of a process with a single character process name, differing from the original file name. This is often done by adversaries while staging, executing temporary utilities, or trying to bypass security detections based on the process name. |
update |
106 |
|
A suspicious Zoom child process was detected, which may indicate an attempt to run unnoticed. Verify process details such as command line, network connections, file writes and associated file signature details as well. |
update |
106 |
|
Identifies suspicious creation of Alternate Data Streams on highly targeted files. This is uncommon for legitimate files and sometimes done by adversaries to hide malware. |
update |
110 |
|
Detects attempts to install or use Kali Linux via Windows Subsystem for Linux. Adversaries may enable and use WSL for Linux to avoid detection. |
update |
4 |
|
Identifies the use of dsquery.exe for domain trust discovery purposes. Adversaries may use this command-line utility to enumerate trust relationships that may be used for Lateral Movement opportunities in Windows multi-domain forest environments. |
update |
4 |
|
Identifies the use of nltest.exe for domain trust discovery purposes. Adversaries may use this command-line utility to enumerate domain trusts and gain insight into trust relationships, as well as the state of Domain Controller (DC) replication in a Microsoft Windows NT Domain. |
update |
106 |
|
PowerShell Suspicious Discovery Related Windows API Functions |
This rule detects the use of discovery-related Windows API functions in PowerShell Scripts. Attackers can use these functions to perform various situational awareness related activities, like enumerating users, shares, sessions, domain trusts, groups, etc. |
update |
109 |
Detects known PowerShell offensive tooling functions names in PowerShell scripts. Attackers commonly use out-of-the-box offensive tools without modifying the code. This rule aim is to take advantage of that. |
update |
5 |
|
Detects scripts that contain PowerShell functions, structures, or Windows API functions related to token impersonation/theft. Attackers may duplicate then impersonate another user’s token to escalate privileges and bypass access controls. |
update |
7 |